ETSITS102 795V1.1.1 



(2009-10) 



Technical Specification 



Electromagnetic compatibility and 

Radio spectrum Matters (ERM); 

Testing for Modes 1, 2 and 3 of the 

Digital Private Mobile Radio (DPMR); 

Requirements catalogue 




ETSI TS 102 795 V1.1.1 (2009-10) 



Reference 



DTS/ERM-TGDMR-280 
Keywords 



digital, mobile, private, radio 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.org/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2009. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™, TIPHON™, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 

LTE™ is a Trade Mark of ETSI currently being registered 

for the benefit of its Members and of the 3GPP Organizational Partners. 

GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



ETSI TS 102 795 V1.1.1 (2009-10) 



Contents 



Intellectual Property Rights 4 

Foreword 4 

1 Scope 5 

2 References 5 

2.1 Normative references 5 

2.2 Informative references 5 

3 Definitions and abbreviations 6 

3.1 Definitions 6 

3.2 Abbreviations 6 

4 dPMR requirements catalogue 7 

4.1 Common requirements 7 

4.1.1 Framing 7 

4.1.1.1 Framing functions 10 

4.1.1.2 Packet data framing format 11 

4.1.2 Coding 12 

4.1.2.1 Message frames 25 

4.1.2.1.1 Message frames, Message Information field 30 

4.1.2.2 End frames 34 

4.1.2.3 Packet data coding 38 

4.1.2.4 Short data delivery 40 

4.2 Services 41 

4.2.1 Mode 1 41 

4.3 Channel access 44 

4.3.1 Physical layer 44 

4.3.2 Powersave 49 

4.4 Addressing 52 

4.4.1 Address defined functions 52 

4.4.2 User defined functions 60 

History 71 



£75/ 



ETSI TS 102 795 V1.1.1 (2009-10) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Electromagnetic compatibility and 
Radio spectrum Matters (ERM). 
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Scope 



The present document is to provide a catalogue of requirements extracted from ETSI Specifications. The catalogue has 
been written based on the test specification framework defined in TS 102 351 [2]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 658 (VI. 1.1) "Electromagnetic compatibility and Radio spectrum Matters (ERM); 

Digital Private Mobile Radio (dPMR) using FDMA with a channel spacing of 6,25 kHz". 

[2] ETSI TS 102 35 1 (V2. 1 . 1 ): "Methods for Testing and Specification (MTS); Internet Protocol 

Testing (IPT); IPv6 Testing: Methodology and Framework". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI ETS 300 230: "Radio Equipment and Systems (RES); Land mobile service; Binary 

Interchange of Information and Signalling (BUS) at 1 200 bit/s (BUS 1 200)". 

[i.2] CENELEC EN 6 11 62-1: "Maritime navigation and radiocommunication equipment and systems - 

Digital interfaces - Part 1: Single talker and multiple listeners". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

base station: two frequency duplex equipment with uplink access and downlink re-transmission 

conditionally mandatory: requirement that is supported by a standard conformant equipment if and only if the 
condition(s) stated within its requirement text are met 

NOTE: If one of these conditions is not met the requirement is considered to be not applicable. 

EXAMPLE: Such a condition may be the support of an optional higher level requirement by the equipment. 

conditionally optional: requirement that may be supported by a standard conformant equipment if and only if the 
condition(s) stated within its requirement text are met 

NOTE: If one of these conditions is not met the requirement is considered to be not applicable. 

mandatory: requirement that shall be supported by a standard conformant equipment 

Mobile Station (MS): handheld and fixed stations that are not repeaters are included 

mode 1: peer to peer (direct mode) operation without Base Stations or infrastructure 

mode 2: dPMR systems incorporating one or more Base Stations for repeating or providing system gateways 

mode 3: dPMR systems operating under a managed access mode in systems incorporating one or more Base Stations 

not applicable: requirement that does not have to be met by a standard conformant equipment 

optional: requirement that may be supported by a standard conformant equipment 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACK ACKnowledgment 

AI Air Interface 

ARQ Automatic Retransmission reQuest 

CC Colour Code 

CCH Control CHannel 

CI Call Information 

Cont Continuation flag 

CRC Cyclic Redundancy Checksum for data error detection 

dPMR digital Private Mobile Radio 

DP Data Position 

ET End Type 

FDMA Frequency Division Multiple Access 

EEC Forward Error Correction 

FN Frame Numbering 

HI Header Information 

ID IDentifier 

Ml Mode 1 MS 

M2 Mode 2 MS 

M3 Mode 3 MS 

MS Mobile Station 

NACK Negative ACKnowledgment 

OACSU Off Air Call Set Up 

PAR PARameter data 

PDF Packet Data Format 
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RF 

RSSI 

SLD 

SYNC 

TCH 



Radio Frequency 

Received Signal Strength Indication 

SLow Data 

SYNChronization 

Traffic CHannel 



4 dPMR requirements catalogue 

4.1 Common requirements 



4.1.1 



Framing 



RQ_001_0401 Framing 

TS 102 658 [1] VI. 1.1 Clause: §4.2.2.2 Type: Mandatory 

Applies to: M1,M2, M3 

Requirement: All transmissions are made up from 80 ms (384 bits) frames. 



Normal frames (not packet data) are the concatenation of: 

24 bits of either FrameSync or ColourCode 

72 bits of Control Channel data 

Followed by 4 blocks of 72 bits of payload. 
(An FDMA traffic channel payload transmission illustrated in figure 4. 1 is made up of 80 ms 
payload frames, each comprising 384 bits. 



Specification Text: 
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Figure 4.1 : Payload Frame 





a: 24 bitsFrameSync2 (FS2) or Colour Code (CC) bits 




b: 72 bits Control Channel (CCH) data 




c: 72 bits Traffic channel (TCH) 




d: 72 bits TCH 




e: 72 bits TCH 




f: 72 bits TCH) 


Family: 


No Duphcates 


Test Purposes: 


TP_PMR_0401_01 (Conformance) TP_PMR_0401_02 



(Conformance) TP_PMR_0401_04 (Conformance) 



Type: Mandatory 



RQ_001_0402 Framing 

TS 102 658 [1] VI. 1.1 Clause: §4.2.3.1 

Applies to: Ml, M2, M3 

Requirement: All normal (non packet data) transmissions are made up from an integral number 

of superframes. 



Specification Text: 



The sequence is illustrated in [1], figure 4.2. These transmissions are always started with a 
Header frame containing a preamble (for bit synchronisation) and a frame synch (for frame 
synchronisation). The Header is followed by a series of Superframes that contain both the 
payload (voice or data) and the information about the call such that receiving stations can 
implement late entry. (A call always consists of an integral number of superframes) and is 
terminated by an End frame. 



ETSI 



8 



ETSI TS 102 795 V1.1.1 (2009-10) 



Family: No Duplicates 

Test Purposes: TP_PMR_0402_01 (Conformance) 

RQ_001_0403 Framing 

TS 102 658 [1] VI. 1.1 Clause: §4.2.2.2.1 Type: Mandatory 

Applies to: Ml, M2, M3 

Requirement: Each superframe is the concatenation of four 80 ms frames. 

Specification Text: (Four 80 ms payload frames illustrated in figure 4.2 are concatenated to form a superframe of 

320 ms.) 
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Figure 4.2: Superframe 

Family: No Duplicates 

Test Purposes: TP_PMR_0403_01 (Conformance)TP_PMR_0403_02 (Conformance) TP_PMR_0403_03 

(Conformance) 



RQ_001_0404 Framing 

TS 102 658 [1] VI. 1.1 Clause: §4.2.3.1 Type: Mandatory 

Applies to: Ml, M2, M3 

Requirement: Normal calls with voice or data continuous transmission generated by the radio 

will start with a Header frame, an integral number of superframes and then 
terminated by an End frame. 

Specification Text: (Voice or data payload continuous transmission: 

(These transmissions are always started with a Header frame containing a preamble (for bit 
synchronisation) and a frame synch (for frame synchronisation). The Header is followed by a 
series of Superframes that contain both the payload (voice or data) and the information about 
the call such that receiving stations can implement late entry. A call always consists of an 
integral number of superframes and is terminated by an End frame.) 

No Duplicates 



Family: 

Test Purposes: 



TP_PMR_0404_01 (Conformance) TP_PMR_0404_02 (Conformance) TP_PMR_0404_03 
(Conformance) 



RQ_001_0405 Framing 

TS 102 658 [1] VI. 1.1 Clause: §4.2.3.2 
Applies to: Ml, M2 

Requirement: 



Type: Mandatory 



Calls generated by the radio for the purposes of call set-up or service request etc 
will be that of a concatenated Header frame and an End frame. 

Specification Text: (The transmission illustrated in figure 4.3 may be sent by Mode 1 and Mode 2 systems on a 
traffic channel at the start of a call. They are a concatenation of a Header frame and an End 
frame. Their purpose is to inform the receiving station of the call, type of call or information 
required. ) 



Figure 4.3 : Call Set-up 
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Family: No Duplicates 

Test Purposes: TP_PMR_0405_01 (Conformance) TP_PMR_0405_02 (Conformance) 



RQ_001_0406 Framing 

TS 102 658 [1] VI. 1.1 Clause: §4.2.3.3 Type: Conditionally Mandatory 



Applies to: 
Requirement: 

Specification Text: 



M1,M2, M3 

Calls generated by the radio for the purposes of traffic channel 
acknowledgements will be simply a Header frame. 

(Traffic channel acknowledgements are sent in response to applicable messages back to the 
originator. Acknowledgements are a type of Header that contains information such as 
confirmation of received data, errors in received data etc.) 



Figure 4.4 : Acknowledgement 



Family: No Duplicates 

Test Purposes: TP_PMR_0406_01 (Conformance) TP_PMR_0406_02 (Conformance) TP_PMR_0406_03 

(Conformance) TP_PMR_0406_04 (Conformance) 



RQ_001_0407 Framing 

TS 102 658 [1] VI. 1.1 Clause: §4.2.3.5 
Applies to: M 1 , M2, M3 



Type: Conditionally Mandatory 



Requirement: 



Specification Text: 



IF the radio supports disconnection request 

THEN calls generated by the radio for the purposes of confirming the end of the series of 
exchanges of a call on a traffic channel shall be the concatenation of a Header frame and End 
frame repeated once. 

(Sending stations can signal that all exchanges of a call have been completed by transmitting a 
disconnection request. This is a Header + End frame pair that is repeated illustrated in 
figure 4.5.) 



<J H I E I H I E I) 
Figure 4.5 : Disconnection 



Family: No Duplicates 

Test Purposes: TP_PMR_0407_01 (Conformance) TP_PMR_0407_02 (Conformance) TP_PMR_0407_03 

(Conformance) TP_PMR_0407_04 (Conformance) 



RQ_001_0408 Framing 

TS 102 658 [1] VI. 1.1 Clause: §4.2.3.4 



Type: Conditionally Mandatory 



Applies to: 
Requirement: 

Specification Text: 



Ml, M2, M3 

Calls generated by the radio for the purposes of traffic channel status request 
responses will be a Header frame and End frame. 

(Traffic channel status request acknowledgements illustrated in figure 4.6 are sent by Mode 1 
and Mode 2 systems. As the status information is contained within the End frame then the 
response of a receiving station to a status request call shall be a Header + End frame pair.) 
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Figure 4.6 : Status Request Acknowledgement 

Family: No Duplicates 

Test Purposes: TP_PMR_0408_01 (Conformance) 

RQ_001_0501 Short Data 

TS 102 658 [1] VI. 1.1 Clause: §5.6 Type: Mandatory 

Applies to: M1,M2 

Requirement: Each appended data frame shall contain 72 bits. 

Specification Text: ([1], figure 5.10) 

Family: No Duplicates 

Test Purposes: TP_PMR_0501_01 (Conformance) 

4.1.1.1 Framing functions 

RQ_001_0502 Short Data 

TS 102 658 [1] VI. 1.1 Clause: §5.6 Type: Mandatory 

Applies to: M1,M2 

Requirement: If the appended data is binary format the first octet of the appended data frame 

shall be 11110001. 

Specification Text: ( [ 1 ] , figure 5.10) 

Family: No Duplicates 

Test Purposes: TP_PMR_0502_01 (Conformance), TP_PMR_0502_01 (Interoperability), TP_PMR_0502_02 

(Interoperability) 

RQ_001_0503 Short Data 

TS 102 658 [1] VI. 1.1 Clause: §5.6 Type: Mandatory 

Applies to: M1,M2 

Requirement: If the appended data is BCD format the first octet of the appended data frame 

shall be 11110010. 

Specification Text: ( [ 1 ] , figure 5.11) 

Family: No Duplicates 

Test Purposes: TP_PMR_0503_01 (Conformance) TP_PMR_0503_01(Interoperabihty) 

TP_PMR_0503_02(Interoperability 

RQ_001_0504 Short Data 

TS 102 658 [1] VI. 1.1 Clause: §5.6 Type: Mandatory 

Applies to: M1,M2 

Requirement: If the appended data is 7 bit ISO format the first octet of the appended data 

frame shall be 11110011. 

Specification Text: ( [ 1 ] , figure 5.12) 

Family: No Duplicates 

Test Purposes: TP_PMR_0504_01 (Conformance), TP_PMR_0504_01 (Interoperability) TP_PMR_0504_02 

(Interoperability) 
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RQ_001_0505 Short Data 

TS 102 658 [1] VI. 1.1 Clause: §5.6 Type: Mandatory 

Applies to: Ml, M2 

Requirement: If the appended data is 8 bit ISO format the first octet of the appended data frame shall be 

11110100. 

Specification Text: ( [ 1 ] , figure 5.13) 

Family: No Duplicates 

Test Purposes: TP_PMR_0505_01 (Conformance), TP_PMR_0505_02 (Interoperability) TP_PMR_0505_01 

(Interoperability) 



Type: Mandatory 



RQ_001_0506 Short Data 

TS 102658 [1] VI. 1.1 Clause: %5.6 

Applies to: M1,M2 

Requirement: If the appended data is encoded NMEA data the first octet of the appended data 

frame shall be 11110101. 

Specification Text: ([1], figure 5.14) 

Family: No Duplicates 

Test Purposes: TP_PMR_0506_01 (Conformance), TP_PMR_0506_01 (Interoperability) TP_PMR_0506_02 

(Interoperability) 

RQ_001_0601 Framing 

TS 102 658 [1] VI. 1.1 Clause: §6.1.5 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: IF a MS has not been programmed with specific Colour Code(s) THEN it shall 

determine the correct CC according to the RF frequency used. 

Specification Text: (Where no specific Colour Code has been programmed for a channel, radios shall determine 
the Colour Code applicable for the frequency by the following algorithm: 

CC number = 64 x (f modulo 0,4) where f is the channel freq in MHz.). 
See also [1], table 6.1 

Family: No Duplicates 

Test Purposes: TP_PMR_0601_01 (Conformance) TP_PMR_0601_02(Conformance) 



4.1.1.2 



Packet data framing format 



RQ_001_1128 Packet data frame 

TS 102 658 [1] VI. 1.1 Clause: §11.4 Type: Conditionally Mandatory 

Applies to: M1,M2, M3 

Requirement: IF the radio offers Packet data 

THEN each packet data burst shall consist of up to 8 data frames. 
Specification Text: (The packet burst can consist of up to 8 data frames.) 
Family: No Duplicates 

Test Purposes: None 
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4.1.2 Coding 



RQ_001_1101 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 



Type: Mandatory 



Applies to: M1,M2, M3 

Requirement: Each Header shall have a single bit Preservation field (PM). 

BS is idle. 

1 BS is announcing a preservation 

Specification Text: (The next bit is the Preservation message according to [1] clause 5.5.23 . This bit will be used 



Family: 

Test Purposes: 



by BS downlinks only and MS shall set this to 0.) 

([1], table 5.75) 
No Duplicates 
TP_PMR_1101_01 (Conformance) 



RQ_001_1102 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 



Type: Mandatory 



Applies to: 
Requirement: 

Specification Text: 



Family: 

Test Purposes: 



M1,M2,M3 

Each Header shall have an eleven bits long Message Information field (MI). 

(Finally there are the 1 1 bits of Message Information (MI) that are made up of 3 Ml Type bits 
and 8 MI_Detail bits as described in clause 5.5.19, [1]) 

(table 11.1, [1]) 
No Duplicates 



RQ_001_1103 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Each T' and 3'^'' frame of the Superframe shall start with 24 bit field containing 

the Frame Sync 2 data, as follows: 

Binary: 010111111111011101111101 
Hex: 5F F7 7D 

Specification Text: (The frame is completed by prefixing with either the 24 bits of FS2 (frame numbers 00 or 10) 
or the 24 bits of Colour Code (frame numbers 01 or 11)). 

(clause 6.1.2, [1]) 

The Frame sync 2 sequence contained in the superframe (frames 1 and 3) is a 24 bit sequence 

that shall have the following value: 

Binary: 010111111111011101111101. 

Hex: 5F F7 7D. 

Family: No Duplicates 

Test Purposes: TP_PMR_1 103_01 (Conformance) TP_PMR_1 1 13_02(Conformance) 
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RQ_001_1104 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: Ml, M2, M3 

Requirement: Each 2"'' and 4* frame of the Superframe shall start with 24 bit field containing 

the Colour Code. 

Specification Text: (The frame is completed by prefixing with either the 24 bits of FS2 (frame numbers 00 or 10) 
or the 24 bits of Colour Code (frame numbers 01 or 11)). 

Family: No Duplicates 

Test Purposes: TP_PMR_1 104_01 (Conformance) 

RQ_001_1105 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: After the Priority field there shall be the one bit Preservation field (PM). 

BS downlinks shall set this to 1. All other calls shall set this to 0. 

Specification Text: (The next bit is the Preservation message according to clause 5.5.23, [1]. This bit will be used 
by BS downlinks only and MS shall set this to 0.) 

Family: No Duplicates 

Test Purposes: TP_PMR_1 105_01 (Conformance) 



RQ_001_1106 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 



Applies to: 
Requirement: 



Specification Text: 



M1,M2,M3 

Each frame of a Superframe shall have a Version field (V). 

This field shall be two bits long. 
Values shall be as follows: 
00 Standard TCH content 
Other Reserved 

(The 2 version bits are added according to clause 5.5.37, [1]) 
See also table 5.100, [1] 



Family: No Duplicates 

Test Purposes: TP_PMR_1 106_01 (Conformance) 

RQ_001_1107 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: The Frame Number (FN) field of each Superframe shall be two bits long. Its 

value shall be from 00 to 1 1 (binary). 

Specification Text: (Frame Numbering (FN) is from 00 to 1 1 (1 to 4)). 

Family: No Duplicates 

Test Purposes: TP_PMR_1107_01 (Conformance) 
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RQ_001_1108 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: Ml, M2, M3 

Requirement: Each frame of the Voice Superframe shall state the type of the call through the 

communications mode field (M). This shall have a length of three bits and its 
value shall be as follows: 

Values shall be as follows: 

000 Voice communication (no user data in SLD field) 

001 Voice + slow data (user data in SLD field) 
101 Voice and attached data (Type 2) 

Other Reserved 



Specification Text: 



Family: 

Test Purposes: 



(The communications mode value is added according to the table in clause 5.5.7, [1]). For 
example, if slow data (SLD) is being included within the voice superframe then 
communications mode value is set to 001. 
Table 5.48, [1]. 

000 Voice communication (no user data in SLD field) 

001 Voice + slow data (user data in SLD field) 

010 Data communication type 1 (Payload is user data without FEC) 
Oil Data communication type 2 (Payload is user data with FEC) 

100 Data communication type 3 (Packet data, ARQ method) 

101 Voice and attached data (Type 2) 
Other Reserved 

No Duplicates 

None 



RQ_001_1109 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: M1,M2, M3 

Requirement: Each frame of a Superframe shall have a Communication format field (F). 

This field must be two bits long. 
Values shall be as follows: 

00 Call ALL 

01 Peer-to-peer communication 

10 BS uplink 

11 BS downhnk 

Specification Text: (The communications format bits are now added according to clause 5.5.6. Generally these 
will be set to 0001) 

(peer-to-peer call). 0)occasionally they may be set to 00 (all call) but this is a special case, 
similar to a broadcast. 

See also (table 5.47 [1]) 
Family: No Duplicates 

Test Purposes: None, TP_PMR_1 109_01 (Conformance) 

RQ_001_1110 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: After the Communications Format field there shall be the one bit Priority field 

(EP): 

Normal priority calls shall set this to 0. 

Emergency priority calls shall set this to 1 . 

Specification Text: (The next bit is the Emergency Priority according to clause 5.5. 12, [1]) 
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Family: No Duplicates 

Test Purposes: TP_PMR_1 1 10_01 (Conformance) TP_PMR_1 1 10_02 (Conformance) 



RQ_001_1 111 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Each frame in a Superframe shall have a field containing called or own ID. 

This field shall be 12 bits long and the data it shall contain depends on the Frame 
Numbering field. 

• Frame Numbering will include the upper 12 bits of the called station ID. 
(IDO) 

• Frame Numbering 1 will include the lower 12 bits of the called station ID. 
(IDl) 

• Frame Numbering 2 will include the upper 12 bits of the own ID. (ID2) 

• Frame Numbering 3 will include the lower 12 bits of the own ID. (ID3) 

Specification Text: (FN is followed by 12 bits of the called station address or own ID) as follows: 

The called station ID and own ID make a total of 48 bits. These bits are split into 12 bit blocks 
and one block is included in each of the 4 frames of the superframe. 

• FN 00 will include the upper 12 bits of the called station ID. 

• FN 01 will include the lower 12 bits of the called station ID. 

• FN 10 will include the upper 12 bits of the own ID. 

• FN 1 1 will include the lower 12 bits of the own ID. 

Family: No Duplicates 

Test Purposes: None 



RQ_001_1112 Traffic channel superframe 

TS 102658 [1] VI. 1.1 Clause: §n.l Fype.- Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Each frame of a Traffic channel superframe shall contain an eighteen bits long 

Slow data field (SLD). 

It is contents depends on the Communication mode field (M) value. 

IF the Communications mode is set to 000 (binary) 
THEN the 18 bits of slow user data field are set to zero. 

Specification Text: (If the communications mode is set to 000 the 18 bits of slow user data (SLD) field are set to 
zero). 



Family: 

Test Purposes: 



No Duplicates 
None 
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RQ_001_1113 Traffic channel superframe 

TS 102658 [1] VI. 1.1 Clause: §11.1 ry;?e.- Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: Each frame of a Traffic channel superframe shall contain an eighteen bits long 

Slow data field (SLD). 

It is contents depends on the Communication mode field (M) value. 

IF the Communications mode is set to 001 (binary) 

THEN the Slow user data field shall be assembled as follows: 

Cont. User data Cont. User data 

1 bit 8 bits 1 bit 8 bits 

Continuation Flag: 

User data continues after the following byte. 

1 User data is terminated by the following byte. 

Specification Text: (If the communications mode is set to 001 the 18 bits of slow user data (SLD) field is 
assembled according to clause 5.5.29.1, [1]). 

(Clause 5.5.29.1 [1] Slow data in the voice superframe). 

Each byte of user data is preceded by a continuation flag (Cont.) to inform the receiving party 

if the subsequent byte is the last. 

Cont. User data Cont. User data 

1 bit 8 bits 1 bit 8 bits 

Continuation Flag: 

User data continues after the following byte. 

1 User data is terminated by the following byte. 

Family: No Duplicates 

Test Purposes: TP_PMR_1 1 13_01 (Conformance) TP_PMR_1 1 13_02 (Conformance) 

RQ_001_1114 Traffic channel superframe 

TS 102658 [1] VI. 1.1 Clause: %n.\ Fype.- Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Each frame of a Traffic channel superframe shall contain an eighteen bits long 

Slow data field (SLD). 

It is contents depends on the Communication mode field (M) value. 

IF the Communications mode is set to 101 (binary) 

THEN the Slow user data field shall be assembled as follows: 

Reserved DP Format Cont. Data length (bytes) 

5 bits 2 bits 4 bits 1 bit 6 bits 

DP coding 

00 There is no data in this frame 

01 Reserved 

10 Reserved 

1 1 This frame is the data frame 
Format coding 

0000 Status message 

0001 Precoded message 

0010 Free text message (radio generated data) 

001 1 Short file transfer 

0100 User defined data 1 

0101 User defined data 2 

0110 User defined data 3 

0111 User defined data 4 
Other Reserved 

Continuation flag: 

Data continues after this frame. 

1 Data finishes at this frame. 
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Specification Text: 



Family: 

Test Purposes: 



(If the communications mode is set to 101 the slow user data (SLD) field is assembled 
according to clause 5.5.29.2, [1]). 

Clause 5.5.29.2, [1] Slow data field use with Type 1 or 2 data 

When Type 1 or 2 data is transmitted, the SLD field is used to convey information of data 
format, position and continuation, etc. The SLD field is also used when a voice transmission 
has data appended to the end of the transmission. 

See (table 5.87, [1]) 
No Duplicates 
None 



RQ_001_1115 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Each frame of a Traffic channel superframe shall contain a 7 bit CRC field. 

Involved bits for CRC calculation shall be the ones in fields: Frame Number, 
Called/Own ID, communication mode, communication format, reserved and 
Slow data. (CCH data). 

The polynomial to generate them is X^7 + X'^S + 1 . 

Specification Text: (The 7 bit CRC checksum is added using the polynomial given in clause 7.1) giving a total of 
48 bits 



Family: 

Test Purposes: 



(Clause 7.1 CRC addition, [1]) 



Use CRC 

Frame (CCH) CRC7 

No Duplicates 

None 



Polynomial 

X'^7 + X'^S + 1 



RQ_001_1116 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: The Control CHannel (CCH) field shall be separated into 6 bytes. Each of these 

bytes shall be coded by shortened 12,8 Hamming code with: 

X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit) 
C3,C2,C1,C0 is parity bit (4 bit) 

The Generator matrix is as follows: 
12 11 10 9 8 7 6 5 4 3 2 1 
X7 X6 X5 X4 X3 X2 XI 1 C3 C2 CI CO 

1100000001110 

2010000000111 

3001000001010 

4000100000101 

500001000101 1 

6000001001 100 

7000000100110 

800000001001 1 
The Shortened Hamming code (12,8) Polynomial is XM + X + 1. 
This gives the 6x12 CCH bit blocks. 
See figure 6 [1]. 
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Specification Text: 



Family: 

Test Purposes: 



(These 48 bits are now separated into 6 bytes. Each byte is now coded by a shortened 

12,8 Hamming Code (clause 7.2 [1]) giving 6x12 bit blocks.) 

(Clause 7.2 Hamming code, [1]) 

A shortened Hamming code (12,8) is employed and the generator matrix is shown below: 

X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is Parity bit (4 bit). 

(table 7.3, [1]: Generator matrix) 

Shortened Hamming code (12,8) Polynomial: XM + X + 1. 

No Duplicates 

None 



RQ_001_1117 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: The 6x12 CCH bit blocks shall be interleaved using the following 12x6 

interleaving matrix: 

12 3 4 5 6 

1 1 13 25 37 49 61 

2 2 14 26 38 50 62 

3 3 15 27 39 5163 

4 4 16 28 40 52 64 

5 5 17 29 41 53 65 

6 6 18 30 42 54 66 

7 7 19 31 43 55 67 

8 8 20 32 44 56 68 

9 9 21 33 45 57 69 

10 10 22 34 46 58 70 

11 1123 35 47 59 71 

12 12 24 36 48 60 72. 

This gives the interleaved CCH data. 

Specification Text: (To protect against burst interference, these 6 x 12 bit blocks are now interleaved using the 



Family: 

Test Purposes: 



12x6 TCH interleaving matrix given in table 7.4, [1]) 
(table 7.4, [1]: TCH Interleaving matrix) 

No Duplicates 

None 



RQ_001_1118 Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: The interleaved CCH data shall be scrambled using the polynomial X'^9 + X'^5 + 

1 with an initial preset value of all "l"s. 

Specification Text: (Then the interleaved CCH data is scrambled using the polynomial given in clause 7.3, [1].) 
(Clause 7.3, [1] Scrambling) 
The scrambling polynomial is X'^9 + X'^5 + 1 with an initial preset value of all "l"s. 

Family: No Duplicates 

Test Purposes: None 
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RQ_001_1119 Voice Traffic channel superframe 

TS 102 658 [1] VI. 1.1 Clause: §11.1 Type: Mandatory 



Applies to: 
Requirement: 

Specification Text: 

Family: 

Test Purposes: 



Ml, M2, M3 

Each frame of the voice Superframe shall end with four 72 bits long Traffic 
Channel (TCH) fields. Each field shall contain the 72 bit block of Forward Error 
corrected vocoder data. 

(Finally the 4 x 72 bit blocks of Forward Error corrected vocoder data (TCH) are appended). 

No Duplicates 

None 



RQ_001_1120 

TS 102 658 [1] VI 
Applies to: 
Requirement: 



Voice Traffic channel superframe 

1 . 1 Clause: §11.1 Type: Mandatory 

Ml, M2, M3 



In a voice transmission, when the PTT is released before the end of the current 
Superframe the current frame and the subsequent frames until the end of the 
Superframe shall be completed using silence data for the Traffic Channel field. 

Specification Text: (If the PTT is released before the end of the current superframe, then the superframe will be 
completed using silence data for the TCH ("silence data" is the vocoder output data when no 
sound is input)). 

Family: No Duplicates 

Test Purposes: None 



RQ_001_1 121 Voice + Attached Data 

TS 102 658 [1] VI. 1.1 Clause: §11.1.1 Type: Conditionally Mandatory 

Applies to: M1,M2 

Requirement: IF the current transmission is voice plus appended data AND the PTT key is 

released before the end of the current Superframe 

THEN the current frame shall be completed using silence data for the Traffic 
Channel field and subsequent frames shall be coded as Type 2 data frames. 

Specification Text: (Within each superframe, there are 4 payload frames. 



Family: 

Test Purposes: 



For this example illustrated in figure 1 1.2, [1] we shall assume that the PTT is released in 
frame 2 and the voice codec data stops. 36 bytes of data with FEC (type 2) shall be attached. 
As each frame has a capacity of 20 bytes of type 2 data, both frames 3 and 4 shall be required.) 

No Duplicates 
None 



RQ_001_1 122 Voice + Attached Data 

TS 102 658 [1] VI. 1.1 Clause: §11.1.1 Type: Conditionally Mandatory 

Applies to: Ml, M2 

Requirement: IF the current transmission is voice plus attached data AND the PTT key is 

released before the end of the current Superframe 

THEN Data Position (DP) in the Slow Data (SLD) field shall indicate if the 
frame contains voice or data information as follows: 

Cont. User data Cont. User data 

1 bit 8 bits 1 bit 8 bits 

Continuation Flag: 

User data continues after the following byte. 

1 User data is terminated by the following byte. 
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Specification Text: (The SLD field in each of these fi-ames is composed as illustrated in figure 11.3, [1]:) 
(See figure 11.3, [1]) 

Family: No Duplicates 

Test Purposes: None 



RQ_001_1123 Type 1 data 

TS 102 658 [1] VI. 1.1 Clause: §11.2 



Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 



Family: 

Test Purposes: 



Ml, M2, M3 

IF the radio ofi^ers Type 1 data 

THEN the communications mode (M) field in the header fi^ame shall be set to 
010 (binary). 

(The communications mode, 010 is added (clause 5.5.7, [1])). 
(Table 5.48, [1]) 

000 Voice communication (no user data in SLD field) 

001 Voice + slow data (user data in SLD field) 

010 Data communication type 1 (Payload is user data without FEC) 
Oil Data communication type 2 (Payload is user data with FEC) 

100 Data communication type 3 (Packet data, ARQ method) 

101 Voice and appended data (Type 2) 
Other Reserved 

No Duplicates 

None 



RQ_001_1124 Type 1 data 

TS 102 658 [1] VI. 1.1 Clause: §11.2 



Type: Conditionally Mandatory 



Applies to: Ml, M2, M3 

Requirement: IF the radio ofi'ers Type 1 data 

THEN the Slow data field (SLD) shall be used to convey information of data 
format, position and continuation, etc. 

Data shall be formatted as follows: 

Reserved DP Format Cont. 

5 bits 2 bits 4 bits 1 bit 



Data length (bytes) 
6 bits 



Data Position (DP): 

00 There is no data in this frame 

01 Reserved 

10 Reserved 

1 1 This frame is the data frame 

Format: 

0000 Status message 

0001 Precoded message 

0010 Free text message (radio generated data) 

001 1 Short file transfer 

0100 User defined data 1 

0101 User defined data 2 

0110 User defined data 3 

0111 User defined data 4 

Other Reserved 

Continuation flag: 

Data continues after this frame. 

1 Data finishes at this frame. 
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Specification Text: 



Family: 

Test Purposes: 



(Then there are the 18 bits of the slow user data field (SLD)). These bits are set according to 

clause 5.5.29.2, [1] depending on the data to be transmitted. 

(Clause 5.5.29.2, [1] Slow data field use with Type 1 or 2 data). 

When Type 1 or 2 data is transmitted, the SLD field is used to convey information of data 

format, position and continuation, etc. The SLD field is also used when a voice transmission 

has data appended to the end of the transmission. 

(table 5.87, [1])DP coding and Format coding 

No Duplicates 

None 



RQ_001_1125 Type 1 data 

TS 102 658 [1] VI. 1.1 Clause: %n.2 



Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Ml, M2, M3 

IF the radio offers Type 1 data 

THEN the Control CHannel (CCH) field shall be separated into 6 bytes. Each of 
these bytes shall be coded by shortened 12,8 Hamming code, as shown in 
clause 7.3, [1] 

X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is parity bit 
(4 bit). 

The Generator matrix is as follows: 
12 11 10 9 8 7 6 5 4 3 2 1 
X7 X6 X5 X4 X3 X2 XI 1 C3 C2 CI CO 

1 

1 1 

1 

1 

1 1 



10 1 
010000000 
10 1 
000100000 
10 1 
10 1 
000000100 



80000000100 





1 

1 1 



The Shortened Hamming code (12,8) Polynomial is XM + X + 1. 
This gives the 6x12 Type 1 data CCH bit blocks. 

Specification Text: (These 48 bits are now separated into 6 bytes. Each byte is now coded by a shortened 
12,8 Hamming Code (clause 7.2, [1]) giving 6x12 bit blocks.) 
(Clause 7.2, [1] Hamming code) 

A shortened Hamming code (12,8) is employed and the generator matrix is shown below: 
X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is Parity bit (4 bit), 
(table 7.3, [1]: Generator matrix) 
Shortened Hamming code (12,8) Polynomial: XM + X + 1. 

Family: No Duplicates 

Test Purposes: None 



RQ_001_1126 Type 1 data 

TS 102 658 [1] VI. 1.1 Clause: §11.2116, 17 
Applies to: M 1 , M2, M3 



Type: Conditionally Mandatory 
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Requirement: 



The 6x12 Type 1 data CCH shall be interleaved using the following 12x6 
interleaving matrix: 



1 



7 7 



9 9 



2 3 4 5 6 

13 25 37 49 61 

14 26 38 50 62 

15 27 39 5163 

16 28 40 52 64 

17 29 41 53 65 

18 30 42 54 66 

19 31 43 55 67 

20 32 44 56 68 

21 33 45 57 69 

10 10 22 34 46 58 70 

11 1123 35 47 59 71 

12 12 24 36 48 60 72. 

This gives the Type 1 interleaved CCH data. 

Then a 288 bit block of uncorrected user data is added 

Specification Text: (To protect against burst interference, these 6 x 12 bit blocks are now interleaved using the 12 
X 6 TCH interleaving matrix given in table 7.4) 

(Next the 288 bit block of uncorrected user data are appended.) 

(Clause 7.4, [1] Interleaving) 

There are two interleaving matrices, one for the TCH and one for the HI field. 

TCH interleave structure matrix: 

table 7.4, [1]: TCH Interleaving matrix 

Family: No Duplicates 

Test Purposes: None 

RQ_001_1127 Type 1 data 

TS 102 658 [1] VI. 1.1 Clause: §11.2 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: The Type 1 interleaved CCH data bits and appended data blocks will be 

scrambled using the polynomial ^^9 + X'^5 + 1 with an initial preset value of all 

"l"s. 

Specification Text: (Finally the interleaved TCH data and appended data blocks are scrambled using the 
polynomial given in clause 7.3) 
(Clause 7.3, [1] Scrambling) 
The scrambling polynomial is X'^9 + X'^5 + 1 with an initial preset value of all "l"s. 

Family: No Duplicates 

Test Purposes: None 



Type: Conditionally Mandatory 



RQ_001_1129 Packet data frame 

TS 102 658 [1] VI. 1.1 Clause: %nA 

Applies to: Ml, M2, M3 

Requirement: IF the radio offers Packet data 

THEN each frame is numbered in the three bits long data frame number (N) field. Its value 
shall be from 000 to 1 1 1 (binary). 

Specification Text: (The current data frame number (N) is from 000 to 111.) 

Family: No Duplicates 

Test Purposes: TP_PMR_1129_01 (Conformance) 
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RQ_001_1130 Packet data frame 

TS 102 658 [1] VI. 1.1 Clause: §11.4 Type: Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: IF the radio offers Packet data 

THEN each frame shall have an 8 bits long field Data length (LEN), giving the number of data 
bytes contained in the current burst. 

Specification Text: (N is followed by 8 bits that give the total number of data bytes contained in the current burst.) 

Family: No Duplicates 

Test Purposes: TP_PMR_1130_01 (Conformance) 

RQ_001_1131 Packet data frame 

TS 102 658 [1] VI. 1.1 Clause: §11.4 Type: Conditionally Mandatory 

Applies to: M1,M2, M3 

Requirement: IF the radio offers Packet data 

THEN the 14 bits long field (DUMMY) shall always set to 0. 
Specification Text: (This is followed by 14 dummy bits that are set to zero.) 
Family: No Duplicates 

Test Purposes: None 

RQ_001_1132 Packet data frame 

TS 102 658 [1] VI. 1.1 Clause: §1 1.4 Type: Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: IF the radio offers Packet data: 

THEN the 16 bits long field, CRC for DATA field (CRC-D) of the current frame shall be 
calculated with the polynomial X'^16 + X'^12 + X'^5 + 1. 

Specification Text: (The next 16 bits are the CRC for the data field contained in this burst.) 

Family: No Duplicates 

Test Purposes: None 

RQ_001_1133 Packet data frame 

TS 102 658 [1] VI. 1.1 Clause: §11.4 Type: Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: IF the radio offers Packet data 

THEN a 7 bit CRC checksum shall be calculated on the above 41 bits, using the X'^? + X'^3 + 1 
polynomial. 

The concatenation of above 48 bits shall be defined and referred as the parameter data (PAR) 

Specification Text: (The 7 bit CRC checksum is added to these 41 bits using the polynomial given in 
clause 7.1, [1] giving a total of 48 bits.) 

Clause 7.1, [1] CRC addition 

Use CRC Polynomial 

Frame (CCH) CRC7 X'^7 + X'^3 + 1 

Family: No Duplicates 

Test Purposes: TP_PMR_1 1 33_01 (Conformance) 
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RQ_001_1134 Packet data frame 

TS 102 658 [1] VI. 1.1 Clause: §11A 
Applies to: Ml, M2, M3 



Type: Conditionally Mandatory 



Requirement: 



IF the radio offers Packet data 

THEN each data burst frame the 48 bits referred as parameter data (PAR) shall be separated 
into 6 bytes. Each of these bytes shall be coded by shortened 12,8 Hamming code where: 

X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): 
C3,C2,C1,C0 is parity bit (4 bit). 
The generator matrix is: 





12 11 10 9 8 7 6 5 4 3 2 1 


X7X6X5X4X3X2X1 


1C3C2C1C0 


1 


1 











1 1 


1 


2 


1 











1 


1 1 


3 





1 








1 


1 


4 





1 








1 


1 


5 





1 








1 


1 1 


6 








1 





1 1 





7 











1 


1 


1 


8 











1 





1 1 



The Shortened Hamming code (12,8) Polynomial is XM + X + 1. 

This will generate a 6x12 bit Packet data blocks 

Specification Text: (These 48 data bits are now separated into 6 bytes. Each byte is now coded by a shortened 12,^ 
Hamming Code (clause 7.2, [1]) giving 6x12 bit blocks.) 

(Clause 7.2, [1] Hamming code) 

A shortened Hamming code (12,8) is employed and the generator matrix is shown below: 
X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is Parity bit (4 bit). 
(table 7.1, [1]): Generator matrix 

Shortened Hamming code (12,8) Polynomial: XM + X + 1. 
Family: No Duplicates 

Test Purposes: None 



RQ_001_1135 Packet data frame 

TS 102 658 [1] VI. 1.1 Clause: %nA 

Applies to: Ml, M2, M3 

Requirement: IF the radio offers Packet data 



Type: Conditionally Mandatory 



THEN the 6 x 12 bit Packet data blocks shall be interleaved using the following 12x6 
interleaving matrix: 



1 



2 3 4 5 6 

13 25 37 49 61 

14 26 38 50 62 

15 27 39 5163 

16 28 40 52 64 

17 29 41 53 65 

18 30 42 54 66 

19 31 43 55 67 

20 32 44 56 68 

21 33 45 57 69 

10 10 22 34 46 58 70 

11 1123 35 47 59 71 

12 12 24 36 48 60 72 

This 72 generated bit shall be referred as the interleaved PAR DATA. 



9 9 
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Specification Text: (To protect against burst interference, these 6 x 12 bit blocks are now interleaved using the 
12x6 TCH interleaving matrix given in clause 7.4, [1]) 
Clause 7.4, [1]: Interleaving 

There are two interleaving matrices, one for the TCH and one for the HI field. 
TCH interleave structure matrix: 
table 7.4, [1]: TCH Interleaving matrix 

Family: No Duplicates 

Test Purposes: None 



RQ_001_1136 Packet data frame 

TS 102 658 [1] VI. 1.1 Clause: §1 1.4 1[9 Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Ml, M2, M3 



IF the radio offers Packet data 



THEN the interleaved PAR DATA and the DATA frames are scrambled using the polynomial 
XA9 + x^5 + 1 with an initial preset value of all "l"s. 



Specification Text: (Next the associated data frames are appended to the interleaved PAR data and scrambled 
using the polynomial given in clause 7.3, [1].) 

(Clause 7.3, [1] Scrambling) 

The scrambling polynomial is X'^9 + X'^S + 1 with an initial preset value of all " l"s. 

Family: No Duplicates 

Test Purposes: None 

4.1.2.1 Message frames 



RQ_001_1137 

TS 102 658 [1] VI. 
Applies to: 
Requirement: 

Specification Text: 

Family: 

Test Purposes: 



Message frames 

1 . 1 Clause: §11.5 

M1,M2,M3 



Type: Mandatory 



Each Message frame shall start with a preamble field, at least 72 bits long, 
composed by a repetition of a byte containing the value 5F (HEX). If more than 
72 bits are sent then the same 5F (HEX) data shall be used. 

The message is completed by prefixing with the 48 bit FS 1 synchronization sequence (see 
note) (and then prefixing the synchronization sequence with a minimum of 72 bits of 
preamble). 

No Duplicates 

None 



RQ_001_1138 Message frames 

TS 102658 [1] VI. 1.1 Clause: %n.5 ry/?e.- Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: If the Message frame is not a Packet data header 

THEN the Frame synchronization sequence field shall be made by following 6 
bytes: 57 FF 5F 75 D5 77 (all in HEX). This is referred as Frame 
synchronization sequence 1 . 
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Specification Text: 



Family: 

Test Purposes: 



(The header is completed by prefixing with the 48 bit FS 1 synchronization sequence) and then 

prefixing FS 1 with a minimum of 72 bits of preamble 

(Clause 6.1.1, [1]FS1) 

The Frame sync 1 sequence contained in the non packet data Header frame (Header 1) is a 

48 bit sequence that shall have the following value: 

Binary: 010101111111111101011111011101011101010101110111. 

Hex: 57 FF 5F 75 D5 77. 

No Duplicates 

TP_PMR_1138_01 (Conformance), TP_PMR_1138_02 (Conformance), TP_PMR_1138_03 
(Conformance) 



RQ_001_1139 Message frames 

TS 102 658 [1] VI. 1.1 Clause: %n.5 



Type: Conditionally Mandatory 



Applies to: Ml, M2, M3 

Requirement: If the Message frame is a Packet data header 

THEN the Frame synchronization sequence field shall be made by following 
6 bytes: FD 55 F5 DF 7F DD (all in HEX). This is referred as Frame 
synchronization sequence 4. 

Specification Text: 

NOTE 1 : (In the case where this is a Packet Data Header, the 48 bit FS4 synchronization sequence is used.) 

Clause 6.1.4, [1] FS4 

The Frame sync 4 sequence contained in the Packet Data Header frame (Header 2) is a 48 bit 

sequence that shall have the following value: 

Binary: 111111010101010111110101110111110111111111011101. 

Hex: FD 55 F5 DF 7F DD. 

Family: RQ 0907 

Test Purposes: TP_PMR_0907_01 (Conformance) 

RQ_001_1140 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Each Message shall be identified by the Message Type (MT) field. This shall 

have a length of four bits and its value shall be as follows: 

0000 Communication start Header (a superframe follows) 

0001 Connection request Header (an END frame follows) 

0010 Unconnect request Header (an END frame follows) 

001 1 ACK (this a single frame, ACK or NACK is differentiated by the CI 
bits setting) 

0100 System request Header (an END frame follows) 

0101 ACK Header reply to a system request (a superframe follows) 

0110 System delivery Header (a superframe follows) 

0111 Status polling response Header 

1000 Status polling request Header 

1001 BS command/response header 

1010 BS access header 

1011 Broadcast 

1 100 Beacon ahoy/random access request 

1101 Reserved 

1110 UDT header 

1 1 1 1 UDT appended data 

Specification Text: (First there are 4 bits allocated to Message Type (MT) which is selected according to 
clause 5.5.20, [1].) 
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Family: No Duplicates 

Test Purposes: TP_PMR_1 140_01 (Conformance), TP_PMR_1 140_02 (Conformance), TP_PMR_1 140_03 

(Conformance) 

RQ_001_1141 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Each Header shall have a 24 bit long field containing the called station ID. 

Specification Text: (MT is followed by the 24 bits of the called station ID.) To this the 24 bits of the own ID is 
added. 

Family: No Duplicates 

Test Purposes: TP_PMR_1141_01 (Conformance) 

RQ_001_1142 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 Type: Mandatory 

Applies to: Ml, M2, M3 

Requirement: Each Header shall have a 24 bit long field containing the own ID. 

Specification Text: MT is followed by the 24 bits of the called station ID. (To this the 24 bits of the own ID is 
added.) 

Family: No Duplicates 

Test Purposes: TP_PMR_1 142_01 (Conformance) 

RQ_001_1143 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Each Header shall state the type of the call through a three bits long 

communications mode field, as follows: 

000 Voice communication (no user data in SLD field) 

001 Voice + slow data (user data in SLD field) 

010 Data communication type 1 (Payload is user data without FEC) 
Oil Data communication type 2 (Payload is user data with FEC) 
100 Data communication type 3 (Packet data, ARQ method) 
10 Voice and appended data (Type 2) 

110 Service request (as defined by MI_type) 

111 Reserved 

Specification Text: (The communications mode value is added according to the table in clause 5.5.7, [1].) 
Family: No Duplicates 

Test Purposes: None 



RQ_001_1144 Message frames 

TS 102658 [1] VI. 1.1 Clause: %n.5 



Type: Mandatory 



Applies to: M 1 , M2, M3 

Requirement: Each Header shall have a two bits long Communication format field (F). 

This shall be as follows: 

Values shall be as follows: 

00 Call ALL 

01 Peer-to-peer communication 

10 BS upHnk 

11 BS downlink 
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Specification Text: (The communications format bits are now added according to clause 5.5.6, [1]. Generally these 
will be set to 0001 (peer-to-peer call). Occasionally they may be set to 00 (all call) but this is a 
special case, similar to a broadcast.) 
(table 5.47, [1]) 

Family: No Duplicates 

Test Purposes: TP_PMR_1 144_01 (Conformance) 



RQ_001_1145 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 



Type: Mandatory 



Applies to: 
Requirement: 

Specification Text: 

Family: 

Test Purposes: 



Ml, M2, M3 



Each Header shall have a single bit Priority field (EP). 

Normal priority 

1 Emergency priority 

{The next bit is the Emergency Priority according to clause 5.5.12, [1]) 
No Duplicates 



RQ_001_1152 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 Type: Mandatory 

Applies to: Ml, M2, M3 

Requirement: The 72 bits of MI data shall be used to calculate an 8 bit checksum, generated by 

the X'^8 + X'^2 H- X'^ 1 H- 1 polynomial. This 8 bits are added, giving a total of 
80 bits. 

Specification Text: (The 8 bit CRC checksum is added using the polynomial given in clause 7.1, [1] giving a total 
of 80 bits.) 
(Clause 7.1, [1] CRC addition) 

Use CRC Polynomial 

Header (HI) CRC8 X^8 h- X'^2 h- X'^l h- 1 



Family: 

Test Purposes: 



No Duplicates 
None 



RQ_001_1153 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 



Type: Mandatory 



Applies to: M 1 , M2, M3 

Requirement: The 80 bits of CRC'ed MI data shall be separated into 10 bytes. Each of these 

bytes shall be coded by shortened 12,8 Hamming code: 

X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit) 
C3,C2,C1,C0 is parity bit (4 bit) 

The Generator matrix is as follows: 
12 11 10 9 8 7 6 5 4 3 2 1 
X7 X6 X5 X4 X3 X2 XI 1 C3 C2 CI CO 
1100000001110 
2010000000111 
3001000001010 
4000100000101 
500001000101 1 
6000001001 100 
7000000100110 
800000001001 1 

The Shortened Hamming code (12,8) Polynomial is X'^4 H- X H- 1. 
This will generate a 12x10 bit blocks. 
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Specification Text: 



Family: 

Test Purposes: 



(These 80 bits are now separated into 10 bytes. Each byte is now coded by a shortened 12,i 
Hamming Code (clause 7.2, [1]) giving 10 x 12 bit blocks.) 

(7.2 Hamming code) 
A shortened Hamming code (12,8) is employed and the generator matrix is shown below: 
X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is Parity bit (4 bit), 
(table 7.1, [1]): Generator matrix 
Shortened Hamming code (12,8) Polynomial: XM + X + 1. 

See figure 10. 

No Duplicates 

None 



RQ_001_1154 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: The 12x10 bit blocks shall be interleaved using the following 12x10 interleaving 

matrix: 



1 



23456789 10 

13 25 37 49 6173 85 97 109 

14 26 38 50 62 74 86 98 110 

15 27 39 5163 75 87 99 111 

16 28 40 52 64 76 88 100 112 

17 29 41 53 65 77 89 101 113 

18 30 42 54 66 78 90 102 114 

19 3143 55 67 79 91 103 115 

8 8 20 32 44 56 68 80 92 104 116 

9 9 21 33 45 57 69 8193 105 117 

10 10 22 34 46 58 70 82 94 106 1 18 

1 1 1 1 23 35 47 59 71 83 95 107 1 19 

12 12 24 36 48 60 72 84 96 108 120 

This gives the interleaved HIO data. 

Specification Text: (To protect against burst interference, these 10 x 12 bit blocks are now interleaved using the 12 
X 10 HI interleaving matrix given in clause 7.4, [1].) 

(clause 7.4, [1] Interleaving) 

There are two interleaving matrices, one for the TCH and one for the HI field. 



NOTE: 



(table 7.5, [1]): HI field Interleaving matrix 
Applied in the Header MIO/MIl, HIO/HIl. 



Family: 

Test Purposes: 



No Duplicates 
None 



RQ_001_1155 Message frames 

TS 102 658 [1] VI. 1.1 Clause: %n.5 



Type: Mandatory 



Applies to: Ml, M2, M3 

Requirement: The interleaved MI data shall be scrambled using the polynomial 

XA9 + x'^5 + 1 with an initial preset value of all "l"s. 
This scrambled data shall be referred as MIO data. 

Specification Text: (Then the interleaved MI data is scrambled using the polynomial given in clause 7.3, [1].) 



Family: 

Test Purposes: 



(Clause 7.3, [1] Scrambling) 

The scrambling polynomial is X^9 + X'^5 + 1 with an initial preset value of all "l"s. 

No Duplicates 

None 
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RQ_001_1156 Message frames 

TS 102 658 [1] VI. 1.1 Clause: §11.5 Type: Mandatory 

Applies to: Ml, M2, M3 

Requirement: Each Header shall be made up of the concatenation of Preamble, Frame Sync, 

HIO data. Colour Code data and HIl data. 

Specification Text: (The 24 bit Colour Code is concatenated to the MI data and then the MI data is repeated after 
the CC.)See figure 11.8, [1]. 

Family: No Duplicates 

Test Purposes: None 



4.1.2.1.1 



Message frames, Message Information field 



RQ_001_1146 Message information field 

TS 102 658 [1] VI. 1.1 Clause: §11.5 11 Type: Mandatory 

Applies to: M1,M2, M3 

Requirement: Each Header shall contain the Message Information (MI) field, formed by 3 bits 

of data type and 8 bits of detail. 

The information contained in this field is depending on the Message type: 

Message Information is used to give supplementary data about the call. It has 
different content and purpose depending on the call type: 



Specification Text: 



Use 

Powers a ve 
Tl or T2 Data 
T3 Data (Packet) 



Purpose 

Indicate normal or extended header type 
Indicate the type of data (supplementary service) 
Indicate data frame size and number of frames 



Acknowledgements Indicate ACK or NACK and reason 



MI Type defines the purpose 
MI Type defines the purpose 
MI Type defines the purpose 



System request 

System response 

Delivery Header 

BS Commands 

Ahoys (additional services) 

(Finally there are the 1 1 bits of Message Information (MI) that are made up of 3 MI Type bits 
and 8 MI information bits as described in clause 5.5.19, [1] (see table 11.1). 



table 5.63 [1],: Use of Message Information 



Use 

Powers a ve 
Tl or T2 Data 
T3 Data (Packet) 
Acknowledgements 
Broadcast 
System request 
System response 
Delivery Header 
BS command 
Ahoys 



Purpose 

Indicate normal or extended header type 
Indicate the type of data (supplementary service) 
Indicate data frame size and number of frames 
Indicate ACK or NACK and reason 

MI Type defines the purpose 
MI Type defines the purpose 
MI Type defines the purpose 



Clause 

5.5.19.1 

5.5.19.2 

5.5.19.3 

5.5.19.5 

5.1.19.6 

5.5.19.4 

5.5.19.4 

5.5.19.4 

5.5.19.7 

5.5.19.8) 



NOTE: In the case where this is a Packet Data header, the 48 bit FS4 synchronization sequence is used. Normally 
receiving stations determine the call type from the Header Information but techniques such as 
determination by FS type (as used by ETS 300 230 [i.l], MPT1327 and others) can be equally valid. 



Family: 

Test Purposes: 



No Duplicates 
None 
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RQ_001_1147 Message information field 

TS 102 658 [1] VI. 1.1 Clause: §11.5 <|[7 Type: Conditionally Mandatory 

Applies to: Ml, M2 

Requirement: IF the content of message information type field is 1 1 1 (binary) 

THEN this is an extended wake-up header for traffic channel powersave 
AND the Ml information field contains the number of Headers that follow the 
current one. This value must be at maximum 0000 1111 (binary). 

Specification Text: (Finally there are the 1 1 bits of Message Information (Ml) that are made up of 3 Ml Type bits 
and 8 Ml detail bits as described in clause 5.5.19, [1] (see table 11.1).) 



table 5.63, [1]: Use of Message Information 



Family: 

Test Purposes: 



Use 

Powersave 

Tl or T2 Data 

T3 Data (Packet) 

Acknowledgements 

Broadcast 

System request 

System response 

Delivery Header 

BS commands 

Ahoys 

No Duplicates 

None 



Purpose 

Indicate normal or extended header type 
Indicate the type of data (supplementary service) 
Indicate data frame size and number of frames 
Indicate ACK or NACK and reason 

MI Type defines the purpose 
MI Type defines the purpose 
MI Type defines the purpose 



Clause 

5.5.19.1 

5.5.19.2 

5.5.19.3 

5.5.19.5 

5.1.19.6 

5.5.19.4 

5.5.19.4 

5.5.19.4 

5.5.19.7 

5.5.19.8 



RQ_001_1148 Message information field 

TS 102 658 [1] VI. 1.1 Clause: %n. 5%! Ty/^e.- Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: IF Message type field is either 0000 or 0001 (binary) - Comm. start or Conn, 

request - 

AND the Header is for a Data communication type 1 or 2 transmission 

THEN: 

the 3 MI type field bits shall set to 001 (binary) 
first 4 bits of the detail field shall be set as follows: 

0000 Status message 

0001 Precoded message 

0010 Free text message (radio generated data) 

001 1 Short file transfer 

0100 User defined data 1 

0101 User defined data 2 

0110 User defined data 3 

0111 User defined data 4 
Other Reserved 

last 4 bits of the information field shall be set to 
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Specification Text: 



Family: 

Test Purposes: 



(Finally there are the 1 1 bits of Message Information (MI) that are made up of 3 MI Type bits 
and 8 MI detail bits as described in clause 5.5.19, [1] (see table 11.1).) 



table 5.63, [1]: Use of Message Information 



Use 

Powers a ve 
Tl or T2 Data 
T3 Data (Packet) 
Acknowledgements 
Broadcast 
System reques 
System response 
Delivery Header 
BS commands 
Ahoys 

No Duplicates 

None 



Purpose 

Indicate normal or extended header type 
Indicate the type of data (supplementary service) 
Indicate data frame size and number of frames 
Indicate ACK or NACK and reason 

MI Type defines the purpose 
MI Type defines the purpose 
MI Type defines the purpose 



Clause 

5.5.19.1 

5.5.19.2 

5.5.19.3 

5.5.19.5 

5.1.19.6 

5.5.19.4 

5.5.19.4 

5.5.19.4 

5.5.19.7 

5.5.19.8 



RQ_001_1149 Message information field 

TS 102 658 [1] VI. 1.1 Clause: §11.51? Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 



Ml, M2, M3 

IF Message type field is either 0000 or 0001 (binary) - Comm. start or Conn, 
request - 

AND the Header is for a Packet data communication type 3 transmission 
THEN: 

- the 3 MI type field bits shall set to 01 1 (binary) 

- first 4 bits of the detail field shall be the Packet data frame size, set as 
follows: 

pdS Frame time (ms) Data size bits 

80 288 

1 160 672 

2 240 1 056 

3 320 1 440 
Other Reserved Reserved 

last 4 bits of the detail field shall be the Packet data frame number, set as 
follows: 

pdM Number of Data frames 

1 frame 

1 2 frames 

2 3 frames 

3 4 frames 

4 5 frames 

5 6 frames 

6 7 frames 

7 8 frames 
Other Reserved 

(Finally there are the 1 1 bits of Message Information (MI) that are made up of 3 MI Type bits 
and 8 MI detail bits as described in clause 5.5.19, [1] (see table 11.1).) 
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Table 5.63, [1]: Use of Message Information 



Family: 

Test Purposes: 



Use 

Powersave 

Tl or T2 Data 

T3 Data (Packet) 

Acknowledgements 

Broadcast 

System request 

System response 

Delivery Header 

BS commands 

Ahoys 

No Duplicates 

None 



Purpose 

Indicate normal or extended header type 
Indicate the type of data (supplementary service) 
Indicate data frame size and number of frames 
Indicate ACK or NACK and reason 

MI Type defines the purpose 
MI Type defines the purpose 
MI Type defines the purpose 



Clause 

5.5. 19T 

5.5.19.2 

5.5.19.3 

5.5.19.5 

5.1.19.6 

5.5.19.4 

5.5.19.4 

5.5.19.4 

5.5.19.7 

5.5.19.8 



RQ_001_1150 Message information field 

TS 102 658 [1] VI. 1.1 Clause: §1 1.5 f? Type: Conditionally Mandatory 

Applies to: M2, M3 

Requirement: IF Message is a system transaction header - 

THEN 

- the 3 MI type field bits shall be set as follows: 

000 to 1 10 according to use 
111 Reserved 

- the 8 information bits shall all set to 

Specification Text: (Finally there are the 1 1 bits of Message Information (MI) that are made up of 3 MI Type bits 
and 8 MI detail bits as described in clause 5.5.19, [1] (see table 11.1).) 

Table 5.63: Use of Message Information 

Use Purpose Clause 

Powersave Indicate normal or extended header type 5.5.19.1 

Tl or T2 Data Indicate the type of data (supplementary service) 5.5.19.2 

T3 Data (Packet) Indicate data frame size and number of frames 5.5.19.3 

Acknowledgements Indicate ACK or NACK and reason 5.5. 19.5 

Broadcast 5.1.19.6 

System request MI Type defines the purpose 5.5.19.4 

System response MI Type defines the purpose 5.5.19.4 

Delivery Header MI Type defines the purpose 5.5.19.4 

BS commands 5.5.19.7 

Ahoys 5.5.19.8 

Family: No Duplicates 

Test Purposes: None 
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RQ_001_1151 Message information field 

TS 102 658 [1] VI. 1.1 Clause: §11.5 '][7 Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 



Family: 

Test Purposes: 



Ml, M2, M3 

IF Message type field is 0101 (bin) - Acknowledgement - 

THEN 

- the 3 Ml type field bits shall be set as follows: 

000 Beacon channel ACK 

001 ACK (Rx OK) 

010 N ACK (data error, resend request) 

01 1 NACK (request denied) 
Other Reserved 

- the 8 detail bits shall be set as follows: 

Reason not specified 

1 to 255 ACK / NACK status (rejection reason defined by user) 

(Finally there are the 1 1 bits of Message Information (MI) that are made up of 3 MI Type bits 
and 8 MI detail bits as described in clause 5.5.19.5, [1] (see table 11.1).) 



Table 5.63, [1] 
Use 

Powers a ve 
Tl or T2 Data 
T3 Data (Packet) 
Acknowledgements 
Broadcast 
System request 
System response 
Delivery Header 
BS commands 
Ahoys 

No Duplicates 

None 



: Use of Message Information 
Purpose 

Indicate normal or extended header type 
Indicate the type of data (supplementary service) 
Indicate data frame size and number of frames 
Indicate ACK or NACK and reason 

Ml Type defines the purpose 
Ml Type defines the purpose 
Ml Type defines the purpose 



Clause 

5.5.19.1 

5.5.19.2 

5.5.19.3 

5.5.19.5 

5.1.19.6 

5.5.19.4 

5.5.19.4 

5.5.19.4 

5.5.19.7 

5.5.19.8 



4.1.2.2 



End frames 



RQ_001_1157 End frame 

TS 102 658 [1] VI. 1.1 Clause: §11.6 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Each End frame shall start with a Frame synchronization sequence 3, 24 bits 

long. 

Frame synchronization sequence 3 is made by following 3 bytes: 7D DF F5 (all 
in HEX). 

Specification Text: (Finally the 24 bit FS3 synchronization sequence is prefixed to these end data bits.) 

(Clause 6.1.3, [1]FS3) 

The Frame sync 3 sequence contained in the End frame is a 24 bit sequence that shall have the 

following value: 

Binary: 011111011101111111110101. 

Hex:7DDFF5. 

Family: No Duplicates 

Test Purposes: TP_PMR_1157_01 (Conformance) 
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RQ_001_1158 End frame 

TS 102 658 [1] VI. 1.1 Clause: §11.6 



Type: Mandatory 



Applies to: 
Requirement: 



Specification Text: 



Family: 

Test Purposes: 



Ml, M2, M3 



Each ENDO and END 1 field shall have a two bits long End Type (ET) field 
using the values: 

00 Normal end frame 

01 End frame with status message 

10 Reserved 

11 Reserved 

(The end data starts with the End Type (ET) which is either 00 (normal end frame) or 01 (end 
frame with status message).) 

(Clause 5.5.13, [1] End type) 

Table 5.54, [1] describes the End_Type field. This field is part of an END frame 

(table 5.54, [1]): End type 

No Duplicates 

None 



RQ_001_1159 End frame 

TS 102 658 [1] VI. 1.1 Clause: §11.6 



Type: Mandatory 



Applies to: 
Requirement: 



Ml, M2, M3 



Each ENDO and ENDl field shall have a two bits long acknowledgement request 
(ARQ) field using the values : 

00 No ACK request to called station 

01 ACK request to called station 

10 Reserved 

1 1 Reserved 

Specification Text: (The next 2 bit are the acknowledgement request (ARQ).)00 signifies that no 
acknowledgement is requested and 01 requires an acknowledgement. 

(Clause 5.5.3, [1] ARQ) 

Table 5.44, [1] describes the ARQ field. This field is part of an END frame 

Table 5.44, [1]: ARQ 

Family: No Duplicates 

Test Purposes: TP_PMR_1 159_01 (Conformance) TP_PMR_1 159_02 (Conformance) TP_PMR_1 159_03 

(Conformance) 



RQ_001_1160 End frame 

TS 102 658 [1] VI. 1.1 Clause: §11.6 Type: Mandatory 

Applies to: M1,M2, M3 

Requirement: Each ENDO and ENDl field shall have a four bits long Tx wait time (WAIT) 

field using the values: 

0000 No specified time 

0001 40 ms (half a frame) 

0010 80 ms (one frame) 

001 1 160 ms (two frames) 
0100 320 ms (one superframe) 
Other Reserved 
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Specification Text: (The next 4 bits define any Tx wait time (WAIT)) using the values given in clause 5.5.34, [1]. 
(clause 5.5.34 Tx Wait) 
Table 5.97, [1] describes the Tx_Wait field. This field is part of an END frame 

The Tx_Wait time is implemented by the called station(s) such that other MS who have a 
break-in request for an emergency call pre-keyed by the user may transmit during the specified 
time. 



Family: 

Test Purposes: 



No Duplicates 
None 



RQ_001_1161 End frame 

TS 102 658 [1] VI. 1.1 Clause: §11.6 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Each ENDO and ENDl field shall have a five bits long status message field 

using the values to 3 1 . 

When End Type (ET) field value has been set to 00 (binary) these bits shall be 
considered as dummy data. 

Specification Text: 5 bit of status message will then follow if ET has been set to 01 (or 5 bits of dummy data if 
ET = 00). 

(Clause 5.5.30 Status) 

Table 5.88, [1] illustrated describes the STAT field. This field is part of an END frame 

Family: No Duplicates 

Test Purposes: None 

RQ_001_1162 End frame 

TS 102 658 [1] VI. 1.1 Clause: §11.6 Type: Mandatory 

Applies to: Ml, M2, M3 

Requirement: Each ENDO and ENDl field shall have a four bits long reserved field and shall 

always contain a 0. 

Specification Text: (Finally the 4 reserved bits are set to 0000.) 

Family: No Duplicates 

Test Purposes: None 



RQ_001_1163 End frame 

TS 102 658 [1] VI. 1.1 Clause: %n.6 



Type: Mandatory 



Applies to: 
Requirement: 

Specification Text: 



Family: 

Test Purposes: 



Ml, M2, M3 

In each End frame the End Information (EIO) field shall be used to calculate a 
7 bit checksum, generated by the X'^7 + X'^3 + 1 polynomial. The checksum 
shall be appended, giving a 24 bits field referred as END DATA) 

(The 7 bit CRC checksum is added using the polynomial given in clause 7.1, [1] giving a total 
of 24 bits.) 

(These 24 bits are now separated into 3 bytes. Each byte is now coded by a shortened 12,8 
Hamming Code (clause 7.2, [1]) giving 3 x 12 bit blocks. These 36 bits are now repeated and 
the total 72 bits are scrambled using the polynomial given in clause 7.3, [1].) 

Clause 7.1, [1] 

Frame (CCH) CRC7 X'^7 + X'^3 + 1 

No Duplicates 

None 
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RQ_001_1164 End frame 

TS 102 658 [1] VI. 1.1 Clause: §11.6 Type: Mandatory 



Applies to: 
Requirement: 



Specification Text: 



Family: 

Test Purposes: 



Ml, M2, M3 

In each End frame the END DATA field shall be separated into 3 bytes. Each of 
these bytes shall be coded by shortened 12,8 Hamming code: 

X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit) 
C3,C2,C1,C0 is parity bit (4 bit) 



The Generator matrix is as follows: 


12 11 10 9 8 7 6 5 4 3 2 1 


X7 X6 X5 X4 X3 X2 XI 


1C3C2C1C0 


1 10 


1 1 


1 


201000000 


1 


1 1 


300100000 


1 


1 


400010000 


1 


1 


500001000 


1 


1 1 


600000100 


1 1 





700000010 


1 


1 


800000001 





1 1 



The Shortened Hamming code (12,8) Polynomial is XM + X + 1. 
This gives the Shortened Hamming END DATA. 

(These 24 bits are now separated into 3 bytes. Each byte is now coded by a shortened 

12,8 Hamming Code (clause 7.2, [1]) giving 3x12 bit blocks.) These 36 bits are now repeated 

and the total 72 bits are scrambled using the polynomial given in clause 7.3, [1]. 

Clause 7.2, [1] Hamming code 

A shortened Hamming code (12,8) is employed and the generator matrix is shown below: 

X7,X6,X5,X4,X3,X2,X1,1 is Identity bit (8 bit): C3,C2,C1,C0 is Parity bit (4 bit). 

Shortened Hamming code (12,8) Polynomial: XM + X + 1. 

No Duplicates 

None 



RQ_001_1165 End frame 

TS 102 658 [1] VI. 1.1 Clause: §11.6 Type: Mandatory 



Applies to: 
Requirement: 
Specification Text: 

Family: 

Test Purposes: 



M1,M2,M3 

In each End frame the End Data shall be sent in duplicate. 

These 24 bits are now separated into 3 bytes. Each byte is now coded by a shortened 12,8 
Hamming Code (clause 7.2, [1]) giving 3x12 bit blocks. (These 36 bits are now repeated and 
the total 72 bits are scrambled using the polynomial given in clause 7.3, [1].) 
No Duplicates 



RQ_001_1166 End frame 

TS 102 658 [1] VI. 1.1 Clause: §11.6 Type: Mandatory 

Applies to: M 1 , M2, M3 

Requirement: In each End frame the concatenation of Shortened Hamming END DATA with 

itself shall be scrambled using the polynomial X'^9 + X^5 + 1 with an initial 
preset value of all "l"s. 
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Specification Text: These 24 bits are now separated into 3 bytes. Each byte is now coded by a shortened 12,8 

Hamming Code (clause 7.2, [1]) giving 3 x 12 bit blocks. These 36 bits are now repeated and 
(the total 72 bits are scrambled using the polynomial given in clause 7.3, [1].) 

Clause 7.3, [1] Scrambling 

The scrambling polynomial is X^9 + X^5 + 1 with an initial preset value of all " l"s. 



Family: 

Test Purposes: 



See figure 10, [1]. 
No Duplicates 
None 



4.1.2.3 



Packet data coding 



RQ_001_0901 Type 3 data 

TS 102 658 [1] VI. 1.1 Clause: §9.2 



Type: Conditionally Mandatory 



Applies to: M 1 , M2, M3 

Requirement: IF a radio supports Packet Data message service (Type 3) 

THEN in case of successful reception and decoding of a type 3 packet data 
transmission including a header frame, a sequence of packet data frames, and an 
end frame, a dPMR radio 

shall send an acknowledge message containing information element Call 
Information with value "ACK RX(ok)". 

Specification Text: (For an individual call, the receiving party shall signal to the transmitting party whether the 
data has been received without errors.) 

Family: No Duplicates 

Test Purposes: TP_PMR_0901_01 (Conformance) 



RQ_001_0902 Type 3 data 

TS 102 658 [1] VI. 1.1 Clause: §9.2 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: IF a dPMR radio supports Packet Data message service (Type 3) 

THEN receiving a packet data message (type 3) it shall send a negative acknowledgement 
message 



Specification Text: 



Family: 

Test Purposes: 



NACK when there is an error in the decoded data. The NACk message shall indicate the packet 
data frame number from which to re-transmit the last communication frame. 

Where there where no errors in any of the received packet frames, the response shall be an 
ACK frame with the Acknowledgement type (in the Ml data) set to 001 2. 

(Where errors are detected in any of the received packet frames, the response shall be an 
acknowledgement with the Acknowledgement type (in the MI data) set to OIO2. This is a 
NACK frame. The information bits in the MI data shall denote the number of the last packet 
frame received without error. The NACK retransmit values are given in table 9.1, [1]). 

No Duplicates 

TP_PMR_0902_01 (Conformance) 
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RQ_001_0903 Type 3 data 

TS 102658 [1] VI. 1.1 Clause: §9.7 



Type: Conditionally Mandatory 



Applies to: Ml, M2, M3 

Requirement: IF a dPMR radio supports Packet Data message service (Type 3) 

THEN it shall indicate the completion of a packet data call by sending a 
disconnect request consisting of two consecutive Header frame, End frame pairs. 

Specification Text: See (When that data has been completely transmitted, station A send the disconnect request. 
Since the disconnect is not acknowledged, the header/end is repeated.) 

Family: No Duplicates 

Test Purposes: TP_PMR_0903_01 (Conformance) 



RQ_001_0904 Type 3 data 

TS 102 658 [1] VI. 1.1 Clause: §9.1 



Type: Conditionally Mandatory 



Applies to: Ml, M2, M3 

Requirement: IF a dPMR radio supports Packet Data message service (Type 3) 

AND it receives a negative acknowledgement message (NACK) after a packet 
data message transmission 

THEN it shall re-transmit the frames from the frame number indicated in the 
NACK message. 

Specification Text: (Figure 9.4, [1]) 

Family: No Duplicates 

Test Purposes: TP_PMR_0904_01 (Conformance) 



RQ_001_0905 Type 3 data 

TS 102658 [1] VI. 1.1 Clause: %9.5 



Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Ml, M2, M3 

IF a dPMR radio supports Packet Data message service (Type 3) 

THEN it shall set unused bytes in the DATA information element in the last 
Data Packet Frame to "0" when transmitting Packet data messages. The unused 
bytes are those bytes (if any) exceeding the specified data length up to the 
DATA information element length. 

Specification Text: (The transmitting party will signal the actual length of the valid data contained in each packet 
using the LEN parameter. Any unused bytes of each packet shall be completed with null data 
(all zeroes).) 

Family: No Duplicates 

Test Purposes: TP_PMR_0905_01 (Conformance) 



RQ_001_0906 Type 3 data 

TS 102 658 [1] VI. 1.1 Clause: §9.6 '][1 



Type: Conditionally Mandatory 



Applies to: M1,M2, M3 

Requirement: IF dPMR radio supports Packet Data message service (Type 3) 

THEN it shall in each packet data frame include a 16 bit CRC field (CRC_D) for 
the DATA information element using the Generated Polynomial 
X'^16 + X'^12 + X'^5 + 1 when transmitting a Packet Data message. 
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Specification Text: (A 16 bit CRC checksum is calculated from the contents of the data field in each packet frame, 
CRC-D. 

The Generated Polynomial uses X'^\6 + X'^ll + X'^S + 1. 
This CRC-D checksum is used in the parameter field (PAR) of the packet data frame. 

Family: No Duplicates 

Test Purposes: TP_PMR_0906_01 (Conformance) 

RQ_001_0907 Type 3 data 

TS 102 658 [1] VI. 1.1 Clause: §9.1 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: If the transmission is a type 3 data 

THEN A dPMR radio shall use frame sync 4 (FS4) in the header. 

Specification Text: (Packet data uses a different format to the normal communications frame format. The use of 
frame sync 4 (FS4) indicates that the frames following will be in PDF format). 

Family: No Duplicates 

Test Purposes: TP_PMR_0907_01 (Conformance) 



4.1.2.4 



Short data delivery 



RQ_001_1011 Short Data 

TS 102 658 [1] VI. 1.1 Clause: §10.1.3.4 



Type: Mandatory 



Applies to: 
Requirement: 

Specification Text: 

Family: 

Test Purposes: 



M1,M2 

Each Message shall be identified by the Message Type (MT) field. This shall 
have a length of four bits and its value shall be 0001 . 

(Table 10.11, [1].) 

No Duplicates 

TP_PMR_101 1_01 (Conformance) 



RQ_001_1012 Short Data 

TS 102 658 [1] VI. 1.1 Clause: §10.1.3.4 Type: Mandatory 



Applies to: 
Requirement: 

Specification Text 

Family: 

Test Purposes: 



M1,M2 

Each Message shall have a Communications Mode (M) field. This shall have a length of three 
bits and its value shall be 110. 

(Table 10.11, [1].) 

No Duplicates 

TP_PMR_1012_01(Conformance) 



RQ_001_1013 Short Data 

TS 102 658 [1] VI. 1.1 Clause: §10.1.3.4 



Type: Mandatory 



Applies to: 
Requirement: 

Specification Text: 

Family: 

Test Purposes: 



M1,M2 

Each Message shall have a Message Information Type (MI_Type) field. This shall have a 
length of three bits and its value shall be 000. 

(Table 10.11, [1].) 

No Duplicates 

TP_PMR_1013_01(Conformance) 
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RQ_001_1014 



Short Data 



TS 102 658 [1] VI. 1.1 Clause: §10.1.3.4 Type: Mandatory 

Applies to: Ml, M2 

Requirement: Each Message shall have a Message Information Detail (MI_Det) field. The first 2 bits shall 

correspond to the number of appended UDT frames. 

Specification Text: (Table 10.11, [1].) 

Family: No Duplicates 

Test Purposes: 



RQ_001_1015 

TS 102 658 [1] VI. 
Applies to: 
Requirement: 

Specification Text: 
NOTE: 



Family: 

Test Purposes: 



Short Data 

1.1 C/flMie.- §10.1.3.4 r>'/5e.- Mandatory 

M1,M2 

Each Message shall have a Message Information Detail (MI_Det) field. The last 
6 bits shall correspond to the number of symbols contained in the UDT frames. 

(Table 10.11.) 

The field UAD defines the number of UDT Appended_Data messages concatenated to the 
Short_Data header (OO2 to 1 12 represents one to four Appended_Data messages). The SYMB 
field is applicable for BCD, 7 bit text and 8 bit octet formatted data. If address, binary, 
EN61 162-1 [i.2] or IP address is transported SYMB = 00 OOOO2. For BCD, 7 bit, 8 bit data 
format, SYMB is coded to the number of symbols to be transmitted unless the number of 
symbols is 64 when SYMB = 00 OOOO2. 

No Duplicates 

None 



4.2 



Services 



4.2.1 



Mode 1 



RQ_001_0801 PTT calls 

TS 102658 [1] VI. 1.1 Clause: %%.\ 

Applies to: Ml, M2 

Requirement: A dPMR radio may support PTT calls 

Specification Text: See (table 8.1, [1]). 

Family: No Duplicates 

Test Purposes: CF 0801, lOP 0801 



Type: Conditionally Mandatory 



RQ_001_0802 Late Entry 

TS 102 658 [1] VI. 1.1 Clause: %%.\ 



Type: Mandatory 



Applies to: 

Requirement: 

Specification Text: 

Family: 

Test Purposes: 



Ml, M2, M3 

A dPMR radio shall support late entry for all Voice calls. 

See (table 8.1, [l])in document. 



TP_PMR_0802_01 (Conformance) TP_PMR_0802_02(Conformance) 
TP_PMR_0802_03(Conformance) TP_PMR_0802_04 (Conformance) , 
TP_PMR_0802_02(Interoperability) TP_PMR_0802_03(Interoperability) 
TP_PMR_0802_04 (Interoperabihty) 
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RQ_001_0803 Talking Party ID 

TS 102 658 [1] VI. 1.1 Clause: §8.1 Type: Optional 

Applies to: Ml, M2, M3 

Requirement: A dPMR radio may support Talking Party Identification. 

Specification Text: See (table 8.1, [1]) in document. 

Family: 

Test Purposes: TP_PMR_0803_01 (Conformance), TP_PMR_0803_01 (Interoperability) 

TP_PMR_0803_02(Interoperability) 

RQ_001_0804 Type 2 data 

TS 102 658 [1] VI. 1.1 Clause: §8.1 Type: Optional 

Applies to: M 1 , M2, M3 

Requirement: A dPMR radio may support type 2 Group short Data Message 

Specification Text: (Type 2 data Group Short Data Message) 

Family: No Duplicates 

Test Purposes: TP_PMR_0804_01 (Conformance), TP_PMR_0804_01 (Interoperability) TP_PMR_0804_02 

(Interoperability) 

RQ_001_0805 Type 1 data 

TS 102 658 [1] VI. 1.1 Clause: §8.1 Type: Optional 

Applies to: Ml, M2, M3 

Requirement: A dPMR radio may support Type 1 Group Short Data Message. 

Specification Text: (Type 1 data Group Short Message) 

Family: No Duplicates 

Test Purposes: TP_PMR_0805_01 (Conformance) , TP_PMR_0805_01 (Interoperability) 

TP_PMR_0805_02(Interoperability) 



RQ_001_0806 Type 3 data 

TS 102 658 [1] VI. 1.1 Clause: §8.1 



Type: Optional 



Applies to: 
Requirement: 

Specification Text: 

Family: 

Test Purposes: 



Ml, M2, M3 

A dPMR radio may support Individual Short Data Message service (Type 3, 
Packet data) 

(Type 3 data. Individual Short Data Message). 

No Duplicates 

TP_PMR_0806_01 (Conformance) , TP_PMR_0806_01 (Interoperability) TP_PMR_0806_02 
(Interoperability) 



RQ_001_0807 Type 2 data 

TS 102 658 [1] VI. 1.1 Clause: §8.2 Type: Optional 

Applies to: M1,M2, M3 

Requirement: A dPMR radio may support Type 2 Individual Short data message. 

Specification Text: (Type 2 data. Individual Short Data Message). 

Family: No Duplicates 

Test Purposes: TP_PMR_0807_01 (Interoperability) TP_PMR_0807_02 (Interoperability) 
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RQ_001_0808 Type 1 data 

TS 102 658 [1] VI. 1.1 Clause: §8.1 Type: Optional 

Applies to: Ml, M2, M3 

Requirement: A dPMR radio may support Type 1 Individual Short Data Message service. 

Specification Text: (Type 1 data, Individual Short Data Message). 

Family: No Duplicates 

Test Purposes: TP_PMR_0808_01 (Interoperability) TP_PMR_0808_02(Interoperability) 

RQ_001_0809 Slow User Data 

TS 102 658 [1] VI. 1.1 Clause: §8.1 111 Type: Conditionally Optional 

Applies to: Ml, M2, M3 

Requirement: For Voice group calls a radio may support supplementary service "Slow user 

data". 

Specification Text: (Table 8.1, [1]) 

Family: No Duplicates 

Test Purposes: TP_PMR_0809_01 (Interoperability) TP_PMR_0809_02 (Interoperability) 

RQ_001_0810 Voice + Attached Data 

TS 102 658 [1] VI. 1.1 Clause: §8.1 Type: Conditionally Optional 

Applies to: Ml, M2 

Requirement: For Voice group calls a dPMR radio may support supplementary service "Short 

attached data" . 

Specification Text: (Table 8.1, [1]) 

Family: No Duplicates 

Test Purposes: TP_PMR_0810_01 (Conformance) TP_PMR_0810_02 (Conformance), 

TP_PMR_0810_01 (Interoperabihty) TP_PMR_0810_02 (Interoperabihty) 

RQ_001_0811 OACSU 

TS 102 658 [1] VI. 1.1 Clause: §8.2 111 Type: Conditionally Optional 

Applies to: Ml, M2, 

Requirement: For Voice individual calls a dPMR radio may support supplementary service 

"Off Air Call Set Up (OACSU)". 

Specification Text: (Table 8.1, [1]) 

Family: No Duplicates 

Test Purposes: TP_PMR_08 1 1_01 (Conformance) TP_PMR_08 1 1_02 (Conformance) TP_PMR_08 1 1_03 

(Conformance), TP_PMR_0811_01 (Interoperability) TP_PMR_0811_02 (Interoperability) 

RQ_001_0812 OACSU 

TS 102 658 [1] VI. 1.1 Clause: §8.2 111 Type: Conditionally Optional 

Applies to: M1,M2, 

Requirement: For Voice individual calls a dPMR radio may support supplementary service 

"Cancel call set-up". 

Specification Text: (Table 8.1, [1]) 

Family: 

Test Purposes: TP_PMR_08 1 2_0 1 (Interoperability) 
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RQ_001_0813 Slow User Data 

TS 102 658 [1] VI. 1.1 Clause: §8.1 Type: Conditionally Optional 

Applies to: Ml, M2, M3 

Requirement: For Voice individual calls a dPMR radio may support supplementary service 

"Slow user data". 

Specification Text: (Table 8.1, [1]) 

Family: No Duplicates 

Test Purposes: TP_PMR_08 1 3_01 (Interoperability) TP_PMR_08 1 3_02 (Interoperability) 

RQ_001_0814 Voice + Attached Data 

TS 102 658 [1] VI. 1.1 Clause: §8.1 Type: Conditionally Optional 

Applies to: Ml, M2 

Requirement: For Voice individual calls a dPMR radio may support supplementary service 

"Short attached data". 

Specification Text: (Table 8.1, [1]) 

Family: No Duplicates 

Test Purposes: TP_PMR_0814_01 (Interoperability) TP_PMR_0814_02(InteroperabiUty) 

RQ_001_0815 Short Data 

TS 102 658 [1] VI. 1.1 Clause: §8.1 fl Type: Conditionally Optional 

Applies to: M1,M2 

Requirement: A dPMR radio may support supplementary service "Short data delivery". 

Specification Text: (Table 8.1, [1]) 

Family: No Duplicates 

Test Purposes: None 



4.3 



Channel access 



4.3.1 Physical layer 



RQ_001_1201 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.1 



Type: Mandatory 



Applies to: 
Requirement: 



M1,M2 

A caller radio shall listen before transmit. When the received signal level has not exceeded 
-105 dBm for the duration of the T_ch_chk timer then the radio shall assume the channel to be 
free. 



Specification Text: When determining whether activity is present on a channel, the radio shall monitor the RSSI 
level. (If after a maximum period of time (T_ch_chk) the RSSI level has not exceeded a 
configurable (within a predefined range) threshold RSSI_LO, then the radio shall assume that 
activity is not present on the channel.) 

Family: No Duplicates 

Test Purposes: None 
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RQ_001_1202 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.1 



Type: Conditionally Mandatory 



Applies to: M1,M2 

Requirement: A radio shall listen before transmitting. 

IF the received signal level is equal or above -105 dBm 

AND the radio can synchronize on the channel. 

THEN the radio shall assume that there is dPMR activity on the channel. 

Specification Text: (If the RSSl level does exceed the RSSl_LO threshold, then the MS shall assume that activity 
is present on the channel and it shall attempt to identify that it is compliant with the present 
document.) 

Family: No Duplicates 

Test Purposes: None 



RQ_001_1203 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.2.2 Type: Mandatory 



Applies to: 
Requirement: 

Specification Text: 



Family: 

Test Purposes: 



M1,M2 

IF a MS receives a break-in request during an announced Tx_Wait period it shall audibly 
prompt the user. 

When a transmitting MS involved in a talkgroup call announces a none zero Tx_Wait time then 
the next item shall not be permitted to start during this Tx_Wait time irrespective of any polite 
or impolite criteria employed. 

During the TX_Wait period, MS shall monitor the channel for a possible break-in request. 

(Where an MS receives an emergency break-in request during the announced Tx_Wait time 
then the MS shall generate a suitable audible prompt to the user to leave the channel free for 
the station that has requested the channel.) 

No Duplicates 

None 



RQ_001_1204 

TS 102 658 [1] VI 
Applies to: 
Requirement: 



Channel Access 
1.1 Clause: §12.1.1 
M1,M2 



Type: Mandatory 



A radio shall listen before transmitting. When the received signal level is above -105 dBm and 
the radio manages to synchronize to the channel but the colour code is incorrect then it shall 
assume the activity is interference. 

Specification Text: (If the MS does identify the channel as compliant with the present document, the MS shall 

attempt to identify the Colour Code. If the Colour Code received differs from that personalised 
in the MS then the MS shall assume that the activity is not applicable to this MS.) 

Family: No Duplicates 

Test Purposes: TP_PMR_1204_01 (Conformance) 
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RQ_001_1205 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.2.2 Type: Mandatory 

Applies to: Ml, M2 

Requirement: IF a transmitting radio announces a non zero Tx WAIT time then other radios shall not 

commence any PTT activated transmissions during this Tx WAIT period. 

Specification Text: (When a transmitting MS involved in a talkgroup call announces a non zero Tx_Wait time 
then the next item shall not be permitted to start during this Tx_Wait time irrespective of any 
polite or impolite criteria employed.) 

During the TX_Wait period, MS shall monitor the channel for a possible break-in request. 

Where an MS receives an emergency break-in request during the announced Tx_Wait time 
then the MS shall generate a suitable audible prompt to the user to leave the channel free for 
the station that has requested the channel. 

Family: No Duplicates 

Test Purposes: TP_PMR_1205_01 (Conformance) 



RQ_001_1206 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.2.3.1 Type: Mandatory 



Applies to: 
Requirement: 
Specification Text: 



Family: 

Test Purposes: 

RQ_001_1207 

TS 102 658 [1] VI. 
Applies to: 
Requirement: 

Specification Text: 



M1,M2 

A voice transmission shall be automatically terminated if it exceeds the preset time limit. 

(For a voice call, MSs shall maintain a traffic channel transmit TimeOut timer (TV_Item) 
which limits the time of a single voice transmission item. This timer shall be set to the value of 
TV_Item seconds whenever the PTT key is pressed and counts down to zero. 

If the transmit TimeOut timer expires, then the MS shall complete the current superframe, 
transmit an END frame then stop transmitting. The MS may not re-transmit until PTT has been 
released and pressed again.) 

No Duplicates 

TP_PMR_1206_01(Interoperability) TP_PMR_1206_02(Interoperability) 



Channel Access 
1.1 Clause: §12 
M1,M2,M3 



Type: Optional 



Family: 

Test Purposes: 



When a MS is requested to transmit a response (acknowledgement etc) it may 
transmit if the channel is busy. 

Where an MS has been solicited to transmit a response, the preamble at the start 
of the transmission shall be timed to conform with figure 12.11, [1]. 
Figure 12.1 1, [1] shows the case where MS(A) (or BS) has transmitted a 
message that solicits a response from MS(B). The MS transmitting the response 
shall send its first bit of preamble 30mS from the last bit of the message that 
solicited the response. The diagram does not imply any limitation on the start of 
the MS Tx RF power ramp which does not need to have attained full power for 
the first 24 bits of the preamble. 

(The response shall be sent irrespective of whether the channel is "Idle" or 
"Busy".) 

No Duplicates 

TP_PMR_1207_01 (Conformance) TP_PMR_1207_02 (Conformance) 
TP_PMR_1207_03 (Conformance) 
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RQ_001_1208 Channel Access 

TS 102658 [1] VI. 1.1 Clause: §12.13.1 r>'/?e.- Optional 

Applies to: Ml, M2 

Requirement: When a radio is involved in a voice call it may transmit even if another party to 

the same call is transmitting on the RF channel. 

Specification Text: (While a MS is party to a voice call, it may transmit irrespective of whether the channel is 

"Idle" or "Busy" with 6,25 kHz FDMA activity pertaining to the same voice call) but may not 
transmit if a Tx_Wait time has been invoked and the timer is running. However, for all other 
situations including data transmissions, MSs shall be configurable to employ the following 
levels of "politeness" on a channel. 

Family: No Duplicates 

Test Purposes: TP_PMR_1208_01 (Conformance), 

TP_PMR_1208_01 (Interoperability) TP_PMR_1208_02 (Interoperability) 



RQ_001_1209 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.3.1 Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 

Family: 

Test Purposes: 



Ml, M2, M3 

IF a MS has polite to own Colour Code enabled 

THEN the radio shall not transmit when the RF channel is occupied by a 
transmission using the same Colour Code. 

Polite to own Colour Code: (The MS shall refrain from transmitting on a channel while the 
channel is "Busy" with other 6,25 kHz FDMA activity from MSs using the same Colour Code.) 
For all other types of activity already present on the channel, the MS shall transmit regardless; 

No Duplicates 

TP_PMR_1209_01 (Conformance), TP_PMR_1209_01 (Interoperability) 



RQ_001_1210 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.3.1 



Type: Conditionally Optional 



Applies to: 
Requirement. 



Family: 

Test Purposes: 



M1,M2 

IF a MS has impolite channel access enabled 

THEN it may transmit if the RF channel is occupied by any other signal. 

Specification Text: (Impolite: The radio shall transmit on a channel regardless of any other activity 
(either 6,25 kHz FDMA or otherwise) already present on the channel.) 

No Duplicates 

TP_PMR_1210_01 (Conformance), TP_PMR_1210_01 (Interoperability) 



RQ_001_1211 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.3.1 Type: Conditionally Mandatory 

Applies to: Ml, M2 

Requirement: IF a MS has polite to own Group or Talkgroup enabled 

THEN the radio shall not transmit while the RF channel is occupied by 
transmissions by members of its own group or talkgroup. 

Specification Text: Polite to own Talkgroup: (The radio shall refrain from transmitting on a channel while the 

channel is "Busy" with other 6,25 kHz FDMA activity from MSs within its own talkgroup.)For 
all other types of activity already present on the channel, the radio shall transmit regardless. 

Family: No Duplicates 

Test Purposes: TP_PMR_121 l_01(Conformance), TP_PMR_121 1_01 (Interoperability) 
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RQ_001_1212 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.3.3 Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 

Family: 

Test Purposes: 



M1,M2 

Certain received calls require acknowledgement responses. When these 
acknowledgements are lost because of interference etc they may be repeated. 

IF these acknowledgements are repeated 

THEN they shall be limited to a maximum number of NMl_Rep times. 

(Certain transmissions solicit responses and where these responses are not received (e.g. due to 
collisions, interference etc.) the transmitting entity may repeat the original transmission 
NMl_Rep times.) 

No Duplicates 

TP_PMR_1212_01 (Conformance) TP_PMR_1212_02 (Conformance) TP_PMR_1212_03 
(Conformance), TP_PMR_1212_01 (Interoperability) 



RQ_001_1213 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.2.3.2 Type: Mandatory 



Applies to: 
Requirement: 

Specification Text: 

Family: 

Test Purposes: 



M1,M2 

A data transmission shall be automatically terminated if it exceeds the preset 
time limit. 

(MSs shall maintain a data maximum item duration timer TD_ltem. If the MS reaches the 
maximum item duration TD_ltem, the MS shall discontinue the item immediately and indicate 
to the application layer that the item was not successfully transmitted.) 

No Duplicates 

TP_PMR_ 1 2 1 3_0 1 (Interoperability) TP_PMR_ 1 2 1 3_02(Interoperability) 



RQ_001_1214 

TS 102 658 [1] VI. 
Applies to: 
Requirement: 

Specification Text: 



Family: 

Test Purposes: 



Channel Access 
1.1 Clause: §12.1.1 
Ml, M2, M3 



Type: Mandatory 



Before transmitting, radios shall observe certain minimum times in assessing 
whether an RF channel is busy (T_ch_chk : 100 ms). 

(When determining whether activity is present on a channel, the MS shall monitor the RSSI 
level. If after a maximum period of time (T_ch_chk) the RSSI level has not exceeded a 
configurable (within a predefined range) threshold RSSI_LO, then the radio shall assume that 
activity is not present on the channel.) 

No Duplicates 

None 



RQ_001_1215 Channel Access 

TS 102 658 [1] VI. 1.1 Clause: §12.1.1 Type: Mandatory 

Applies to: Ml, M2 

Requirement: Before transmitting, radios shall observe certain minimum times for trying to 

synchronize to any activity found on the channel (T_ch_free : 200 ms). 

Specification Text: (T_ch_free: Unsynchronizable activity timer: 200 ms.) 

Family: No Duplicates 

Test Purposes: None 
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4.3.2 Powersave 

RQ_001_1001 Powersave 

TS 102 658 [1] VI. 1.1 Clause: §10.1.4.1 Type: Conditionally Mandatory 

Applies to: M1,M2 

Requirement: IF powersave is supported 

AND repeated headers are used for powersave 

THEN the preamble by each header shall be fixed at 72 bits. 

Specification Text: (In the case of repeated Headers for powersave use, the preamble used by each Header shall be 
fixed at 72 bits). 

Family: No Duplicates 

Test Purposes: TP_PMR_1001_01 (Conformance) 



RQ_001_1002 



Powersave 



TS 102 658 [1] VI. 1.1 Clause: §10.1.4.1 Type: Conditionally Mandatory 

Applies to: Ml, M2 

Requirement: IF powersave supported 

THEN when transmitting extended wake-up headers the first 3 bits (Call 
Information Type) of the 1 1 bits of the Call Information (CI) field shall be set to 
'1 ir in these headers. 

Specification Text: These powersave wake-up headers shall be coded according to table 10.12, [1]. 

The 1 1 bits of Call Information (CI) are used as follows: 

(MI Type =111 (extended wake-up Header)). 
Family: No Duplicates 

Test Purposes: TP_PMR_1002_01 (Conformance) 



RQ_001_1003 Powersave 

TS 102 658 [1] VI. 1.1 Clause: §10.1.4.1 Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 



Family: 

Test Purposes: 



M1,M2 

IF powersave supported 

THEN when transmitting extended wake-up headers the last 4 bits of the 1 1 bits 
of the Call Information (CI) field shall indicate the number of Header frames to 
follow. 

MI Information uses that least significant 4 bits to portray when the normal header frame 
occurs: 

(Table 10.12, [1]) 

No Duplicates 

TP_PMR_1003_01 (Conformance) 
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RQ_001_1004 Powersave 

TS 102 658 [1] VI. 1.1 Clause: §10.1.4.1 Type: Conditionally Mandatory 

Applies to: Ml, M2 

Requirement: IF powersave is supported 

THEN the calling radio can be programmed to use up to 15 extended wake-up 
headers for extended wake-up purposes. 

Specification Text: (Radios can be programmed to use up to 15 extended header frames for wake-up purposes. 
This will give a maximum response time of 1,2 seconds). 

Family: No Duplicates 

Test Purposes: None 



RQ_001_1005 Powersave 

TS 102 658 [1] VI. 1.1 Clause: §10.1.4.1 



Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 

Family: 

Test Purposes: 



M1,M2 

IF powersave supported 

THEN a caller using the wake-up procedure shall end the sequence of extended 
wake-up header sending a normal header, indicating the call type in the Call 
Information (CI ) field. 

See (Table 10.13, [1]). 

No Duplicates 

None 



RQ_001_1006 Powersave 

TS 102 658 [1] VI. 1.1 Clause: §10.1.4.2 fl Type: Conditionally Mandatory 

Applies to: M1,M2 

Requirement: IF powersave supported 

THEN the wake-up periods of a radio in standby (sleep mode) shall have a 
duration of at least T_ch_chk. 

Specification Text: Radio in standby (sleep) will be programmed to wake-up and monitor the channel at regular 
intervals. (Each wake-up shall have a minimum duration of T_ch_chk (clause 13.1, [1])). 

Family: No Duplicates 

Test Purposes: None 

RQ_001_1007 Powersave 

TS 102 658 [1] VI. 1.1 Clause: %lQ.lA.2<l2Type: Conditionally Mandatory 

Applies to: Ml, M2 

Requirement: IF powersave supported 

THEN the maximum sampling interval between wake-up periods shall be 
(n-1) X 80ms, where n is the number of extended wake-up headers used. 

Specification Text: The intervals between successive wake-ups shall be dependent on the number of repeated 
Header frames used in extended wake-up according to clause 11.1. 

(The maximum sampling interval between wake-ups shall be: 

T_sam = (n - 1) X 80 ms). 

Where T_sam is the sampling interval and n is the number of extended wake-up Headers used. 
(see clause 13.1, [1] for the T_sam value). 

Family: No Duplicates 

Test Purposes: None 
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RQ_001_1008 Powersave 

TS 102 658 [1] VI. 1.1 Clause: §10.1.4.2 Type: Conditionally Optional 

Applies to: Ml, M2 

Requirement: IF powersave supported 

AND the radio is awaken 

THEN it may return to sleep mode if there is no activity on the channel for the 

duration of T_ch_chk. 

Specification Text: (If the radio wakes and there is no activity on the channel for the duration of T_ch_chk it may 
return to sleep). 

Family: No Duplicates 

Test Purposes: None 



RQ_001_1009 Powersave 

TS 102 658 [1] VI. 1.1 Clause: §10.1.4.2 Type: Conditionally Optional 



Applies to: 
Requirement: 



Specification Text: 

Family: 

Test Purposes: 



M1,M2 

IF powersave supported 

AND the radio is awaken by activity on the channel 

THEN the radio return to sleep mode if the called address in received and 
decoded traffic does not match it own. 

(If the MS wakes and decodes dPMR activity but the called station ID in the Header_Message 
frame does not match the MS individual ID or one of the MS talkgroup IDs, the MS may return 
to sleep.). 

No Duplicates 

None 



RQ_001_1010 

TS 102 658 [1] VI 
Applies to: 
Requirement: 



Powersave 

1.1 Clause: %\Q.\A.2 r>7?e.- Conditionally Optional 

M1,M2 



IF powersave supported 

AND has completed payload or signalling reception 

THEN it may return to sleep. 

Specification Text: If the MS wakes and decodes dPMR activity and the called station ID in the Header_Message 
frame matches the MS individual ID or one of the MD talkgroup IDs, the MS is able to 
calculate from the Ml information bits the point in time when the payload item or signalling 
will begin. (Upon completion of the payload item or signalling the radio may return to sleep 
again.) 

Family: No Duplicates 

Test Purposes: None 
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4.4 Addressing 

4.4.1 Address defined functions 

RQ_001_1301 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: A.1.2.1.1.6 Type: Conditionally Mandatory 

Applies to: M1,M2, M3 

Requirement: A dPMR radio complying to the Standard User Interface shall use a 7 digit 

addressing scheme that is encoded into the 24 bit address field as defined by the 
algorithm: 

SUM( Kl * 1464100, K2 * 146410, K3 * 14641, K4 * 1331, K5 * 121, K6 * 11, K7 ) 

where 

K1,K2,K3 represent decimal symbols in the range to 9. 

K4,K5,K6,K7 represent symbols to base 11 using the digits 0,1,2,3,4,5,6,7,8,9,*. 

The "*" is a symbol that has the value of 10. 

Specification Text: (For equipment compliant with the Standard User Interface radios shall use a 7 
digit addressing scheme that is encoded into the 24 bit address field as detailed 
in annex A.) 

Family: 

Test Purposes: CF 131 1 TP_PMR_131 1_01 (Conformance) TP_PMR_131 1_02 (Conformance) 

TP_PMR_1311_03 (Conformance) TP_PMR_1311_04 (Conformance) 



Specification Text: 



RQ_001_1302 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.1 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: For a dPMR radio complying with the Standard User Interface, dialled digits that 

represent a destination address shall be encoded to give the 24 bit content of the 
Air Interface address field. 

Dialled digits are represented in decimal notation and utilize the numbers "0" to 
"9" and the keys "*" and "#". For an MS fitted with a keypad, the "#" key may 
initiate a call (although other initiate methods may be implemented by a 
manufacturer). (Dialled digits that represent a destination address are translated 
to a form for the Air Interface by a coding algorithm. This is illustrated in figure 
A.2. (see document). 

Address fields in the Air-Interface domain structure has a length of 24 bits.) 

The content of a 24-bit AI MS address field may represent: 

• an MS individual address; 

• an MS group address. 

The Air Interface provides call services for voice and data. The Al also permits 
the call services to be modified. The application that converts the User Interface 
to the Air Interface recognizes the "call modifier" and request the lower layers to 
set appropriate bits in the PDUs carried between the entities. At the User 
Interface, the "call modifier" is indicated by preceding the destination address 
digits with additional "call modifier" digits. 



Family: 

Test Purposes: 



CF 1311 TP_PMR_1311_01 (Conformance) TP_PMR_1311_02 (Conformance) 
TP_PMR_1311_03 (Conformance) TP_PMR_1311_04 (Conformance) 
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RQ_001_1303 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A1.2.1.1 Type: Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: For dPMR radios complying with the Standard User Interface, calls shall be 

addressed to numeric or non-numeric addresses (i.e. addresses containing 
"wildcards") 

Specification Text: (Each call is made to a numeric or non-numeric address (with "wildcards").)The 
mapping between the User-Interface domain and the Air Interface uses a 
reversible coding algorithm. 

MS will establish the call type from analysis of the decoded Air Interface 
address. There are a number of methods by which a MS may distinguish 
between talkgroup and individual calls and these are described in the following 

clauses. 

Family: 

Test Purposes: TP_PMR_ 1 4 1 5_0 1 (Interoperability) TP_PMR_ 1 4 1 5_02 (Interoperability) 



RQ_001_1304 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.1.1.1 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: IF the "wildcard" feature is enabled 

THEN a dPMR radio complying with the Standard User Interface shall identify 
group calls by analysing the decoded air interface address for "wildcards". 

Specification Text: MS will establish the call type from analysis of the decoded Air Interface address. There are a 
number of methods by which a MS may distinguish between talkgroup and individual calls and 
these are described in the following clauses. 

(The MS may discriminate a talkgroup call from an individual call by the use of the 

"wildcard". 

In the User Interface domain structure, if the dialled string represents an MS address, and 

contains a "*" in any of the four least significant characters, then that MS address represents a 

group of MSs.)The "*" character is the "wildcard" and represents all numeric values in that 

digit position, as defined in example 1 to 3. 

EXAMPLE 1: The user dials "012345*" means that the MS is addressing 10 separate MSs 

whose 

individual addresses are "0123450", "0123451", "0123452", "0123453", "0123454", 

"0123455", 

"0123456", "0123457", "0123458", and "0123459". 

EXAMPLE 2: The user dials "01234*6" means the MS is addressing 10 separate MSs whose 

individual 

addresses are "0123406", "0123416", "0123426", "0123436", "0123446", "0123456", 

"0123466", 

"0123476", "0123486", and "0123496". 

EXAMPLE 3: Wildcards may be combined. The user dials "01234**" represents 100 MSs 

in the range "0123400" to "0123499". 

For operators who have no interest in this method of defining talkgroups, the "wildcard" 

feature may be disabled by MS programming. 



Family: 

Test Purposes: 



TP_PMR_1415_01 (Interoperability) TP_PMR_1415_02 (Interoperability) 
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RQ_001_1305 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.1.1.2 Type: Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: IF a dPMR radio complying with the Standard User Interface has one or more 

numeric talk group address stored in memory. 

THEN the radio shall identify group calls by analysing the decoded AI address 
and comparing it to the stored talk group address(es). 

Specification Text: MS will establish the call type from analysis of the decoded Air Interface address. There are a 
number of methods by which a MS may distinguish between taUcgroup and individual calls and 
these are described in the following clauses. 

(The MS equipment may contain predefined parameters prescribing the MS addresses that will 
be interpreted as talkgroup addresses. These addresses may be stored as a list programmed 
during manufacture or before connecting an MS into service.) 



Family: 

Test Purposes: 



TP_PMR_1415_01 (Interoperability) TP_PMR_1415_02 (Interoperability) 



RQ_001_1306 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: %K.\2.\.\3 Type.- Optional 

Applies to: M 1 , M2, M3 

Requirement: A dPMR radio may use a range of addresses that are all talkgroup addresses. 

Specification Text: (The MS equipment may simply rely on a range of addresses that all equipment is known to be 



Family: 

Test Purposes: 



talkgroup addresses.) 
No Duplicates 
None 



RQ_001_1307 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.1. 1.411 Type: Conditionally Mandatory 

Applies to: M1,M2, M3 

Requirement: A dPMR caller radio complying with the Standard User Interface shall encode 

the dialled user digits to a 24 bit air interface address by using the reversible B2 
algorithm. 

Specification Text: (The MS codes the dialled user digits to a 24 bit Air Interface address by using the reversible 
algorithm B2.) 

Family: 

Test Purposes: CF 131 1 TP_PMR_131 1_01 (Conformance) TP_PMR_131 1_02 (Conformance) 

TP_PMR_1311_03 (Conformance) TP_PMR_1311_04 (Conformance) 

RQ_001_1308 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.1.1.5 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: A dPMR callee radio complying with the Standard User Interface shall decode 

the 24 bit air interface address of a received call by using the reverse B2 
algorithm to a 7 digit string. 

IF this 7 digit string contains a "*" character in any of the 4 least significant 
characters, the radio shall compare the received string to its individual address 
for match and ignore any mismatch if there is a "*" character at that position. If 
all other digits match then the radio is party to this talk group call. 
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Specification Text: These rules determine whether a call is to a talkgroup or individual address and will be 
accepted by a MS. 

(All reference to MS in this clause refer to the recipient.) 
MS receives a dPMR call. 

MS uses the reverse of the B2 function specified in clause A. 2. 1.2.6, [1] to translate the AI 
talkgroup address to the User Interface domain. 
(IF digits (User Interface) 

contains a "*" in any of the least significant four characters 
THEN 

each digit received is compared with each corresponding digit of the MS individual address 
except where the received digit is a "*". If there is a match on all applicable digits then this MS 
is party to the talkgroup call.) 
ELSE 

(consists of numeric characters only) 
THEN 
EITHER 

The string of digits received is compared with each corresponding string of talkgroup digits 
that the MS has stored (specifically indicating a talkgroup). 
If there is a match then this MS is party to the talkgroup call. 
OR 

The string of digits received is compared with each corresponding string of individual address 
digits that the MS has stored. 

If there is a match then this MS is party to the individual call. 
ENDIF 



Family: 

Test Purposes: 



TP_PMR_1415_01 (Interoperability) TP_PMR_1415_02 (Interoperability) 



RQ_001_1309 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.1.1.5 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: A dPMR callee radio complying with the Standard User Interface shall decode 

the 24 bit air interface address of a received call by using the reverse B2 
algorithm to a 7 digit string. 

IF this 7 digit string contains only numerical digits 

THEN 

EITHER the radio shall compare the received string to any talk group address 

programmed in memory and if there is a match then the radio is party to this talk 

group call. 

OR the radio shall compare the received string to any individual address 
programmed in memory and if there is a match then the radio is party to this 
individual call. 



£75/ 



56 



ETSI TS 102 795 V1.1.1 (2009-10) 



Specification Text: These rules determine whether a call is to a talkgroup or individual address and will be 
accepted by a MS. 

(All reference to MS in this clause refer to the recipient.) 
MS receives a dPMR call. 

MS uses the reverse of the B2 function specified in clause A. 2. 1.2.6, [1] to translate the AI 
talkgroup address to the User Interface domain. 
IF digits (User Interface) 

contains a "*" in any of the least significant four characters 
THEN 

each digit received is compared with each corresponding digit of the MS individual address 
except where the received digit is a "*". If there is a match on all applicable digits then this MS 
is party to the talkgroup call. 
(ELSE 

(consists of numeric characters only) 
THEN 
EITHER 

The string of digits received is compared with each corresponding string of talkgroup digits 
that the MS has stored (specifically indicating a talkgroup). 
If there is a match then this MS is party to the talkgroup call. 
OR 

The string of digits received is compared with each corresponding string of individual address 
digits that the MS has stored. 

If there is a match then this MS is party to the individual call. 
ENDIF) 



Family: 

Test Purposes: 



TP_PMR_1415_01 (Interoperability) TP_PMR_1415_02 (Interoperability) 



RQ_001_1310 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.1.1.6 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: A dPMR radio complying with the Standard User Interface shall use the 

reversible B2 algorithm to convert between 7 digit string and 24 bit air interface 



Specification Text: 



Family: 

Test Purposes: 



addresses and vice-versa. 

(A MS address is a 7-character numeric string in the range "0000001" to "999****"^ these 
characters are mapped to the Air Interface domain structure bits by the reversible function B2.) 
Addresses may consist of all numeric characters (but the MS must be able to ascertain the 
address is a talkgroup address rather than an individual address). Alternatively any of the last 
four characters may contain one or more "*" characters that explicitly signifies the address is a 
talkgroup address. 



CF 1311 TP_PMR_1311_01 (Conformance) TP_PMR_1311_02 (Conformance) 
TP_PMR_1311_03 (Conformance) TP_PMR_1311_04 (Conformance) 



RQ_001_1311 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.1. 1.6.1 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: A dPMR radio complying with the Standard User Interface shall use the 

following rules for mapping between 7 digit address field (Kl to K7) at the user 
level and the 24 bit address field at the Air interface. 

Kl is the most significant digit. 

K1,K2,K3 represent decimal symbols in the range to 9. 

K4,K5,K6,K7 represent symbols to base 11 using the digits 0,1,2,3,4,5,6,7,8,9,*. 

The "*" is a symbol that has the value of 10. 
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Specification Text: 



The six least significant user dialled digits K2 to K7 in the range "000001" to 
"999999" aj-g converted to the 20 least significant 20 bits of the AI ID using true 
decimal to binary conversion. The most significant user dialled digit Kl is 
converted to the most significant 4 bits of the AI ID using a true decimal to 
binary conversion. 

The following steps are needed to convert the dialled digits to an ID in the AI 
domain: 

a) take the first digit (0 to 9) and multiply by 1 464 100; 

b) take the second digit (0 to 9), multiply by 146 410; 

c) take the third digit (0 to 9) and multiply by 14 641; 

d) take the fourth digit (0 to 9) or * (* has a value of 10) and multiply by 1 331; 

e) take the fifth digit (0 to 9) or * (* has a value of 10) and multiply by 121; 

f) take the sixth digit (0 to 9) or * (* has a value of 10) and multiply by 1 1; 

g) take the seventh digit (0 to 9) or * (* has a value of 10); 
h) add a) to g); and 

i) convert the sum to a 24-bit binary number. 

(K1,K2,K3 represent decimal symbols in the range to 9. 

K4,K5,K6,K7 represent symbols to base 11 using the digits 0,1,2,3,4,5,6,7,8,9,*. 

The "*" is a symbol that has the value of 10. 

The six least significant user dialled digits K2 to K7 in the range "000001" to "999999" are 

converted to the 20 least significant 20 bits of the AI ID using true decimal to binary 

conversion. The most significant user dialled digit Kl is converted to the most significant 4 

bits of the AI ID using a true decimal to binary conversion. 



The following steps are needed to convert the dialled digits to an ID in the AI domain: 

a) take the first digit (0 to 9) and multiply by 1 464 100; 

b) take the second digit (0 to 9), multiply by 146 410; 

c) take the third digit (0 to 9) and multiply by 14 641; 

d) take the fourth digit (0 to 9) or * (* has a value of 10) and multiply by 1 331; 

e) take the fifth digit (0 to 9) or * (* has a value of 10) and multiply by 121; 

f) take the sixth digit (0 to 9) or * (* has a value of 10) and multiply by 1 1; 
g)take the seventh digit (0 to 9) or * (* has a value of 10); 

h) add a) to g); and 

i) convert the sum to a 24-bit binary number.) 



Family: 

Test Purposes: 



Examples are shown in table A. 2, [1]. 

Table A.2.1.1.5.1.2 [1]: Examples of address translation 



User-Interface 

1234567 

468956* 

012345* 

0123460 
999**** 



Air-Interface (Hex) 

1B91FD 

68BF08 

02C00A 

02C00B 

DF6767 



Air Interface (Binary) 

0001 1011 10010001 nil 1101 
0110 1000 1011 nil 0000 looo 

0000 0010 1100 0000 0000 1010 
0000 0010 COOO 0000 0000 101 1 

1101 nil onooinonoom 



CF 1311 TP_PMR_13n_01 (Conformance) TP_PMR_1311_02 (Conformance) 
TP_PMR_1311_03 (Conformance) TP_PMR_1311_04 (Conformance) 
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RQ_001_1312 

TS 102 658 [1] VI. 
Applies to: 
Requirement: 
Specification Text: 



Dialling Plan 

1.1 Clause: %A.\. 2.2 
Ml, M2, M3 



Type: Mandatory 



Family: 

Test Purposes: 



A dPMR radio shall have at least one individual address. 

(An MS is pre-programmed with at least one individual identity.) 

An MS is permitted to have multiple individual identities and one or more talkgroup identities. 

An MS may contain a list of talkgroup identities, which may be pre-programmed or 

dynamically updated (manually or over the Al). 

The User Interface domain maps to the AI address space by the B2 algorithm. 



None 



RQ_001_1313 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.2 Type: Optional 



Applies to: 
Requirement: 

Specification Text: 



Family: 

Test Purposes: 



M1,M2,M3 

A dPMR radio may have multiple individual addresses and one or more talk 
group addresses. 

(An MS is permitted to have multiple individual identities and one or more talkgroup 

identities.) 

Where an MS has more than one individual identity then one of these shall be assigned as the 

primary individual identity. This primary individual identity is the one that shall be used for all 

forms of abbreviated or masked dialling (clauses A. 3. 4. 1.2 and A. 3. 4. 1.3, [1]) 

An MS may contain a list of talkgroup identities, which may be pre-programmed or 

dynamically updated (manually or over the Al). 

No Duplicates 

None 



RQ_001_1314 

TS 102 658 [1] VI 
Applies to: 
Requirement: 



Dialling Plan 

1.1 Clause: %A.\. 2.2 
Ml, M2, M3 



Type: Optional 



A dPMR radio may be programmed with a list of talkgroup identities, which 
may be pre-programmed or dynamically updated (manually or over the Al). 

Specification Text: An MS is pre-programmed with at least one individual or one talkgroup identity. 

An MS is permitted to have multiple individual identities and multiple talkgroup identities. 
(An MS may contain a list of talkgroup identities, which may be pre-programmed or 
dynamically updated (manually or over the Al).) 
The User Interface domain maps to the AI address space by the B2 algorithm. 

Family: No Duplicates 

Test Purposes: None 
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RQ_001_1315 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.3.1 Type: Conditionally Mandatory 



Applies to: 
Requirement: 

Specification Text: 



Family: 

Test Purposes: 



Ml, M2, M3 

For a dPMR radio complying with the Standard User Interface the 7 characters 
used for individual addresses shall contain only the digits "0" to "9". 

(An MS address in the User-Interface structure is defined as 7 characters of which for an 
individual MS address contain the characters "0" to "9".)For a talkgroup address the three most 
significant contain the characters "0" to "9" and least significant four characters contain the 
characters "0" to "9" or"*". 

No Duplicates 

None 



RQ_001_1316 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.3.1 Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 



Family: 

Test Purposes: 



Ml, M2, M3 

For a dPMR radio complying with the Standard User Interface the 7 characters 
used for talkgroup addresses shall be as follows: 

The three most significant contain the characters "0" to "9" and least significant 
four characters contain the characters "0" to "9" or "*". 

An MS address in the User-Interface structure is defined as 7 characters of which for an 
individual MS address contain the characters "0" to "9". (For a talkgroup address the three 
most significant contain the characters "0" to "9" and least significant four characters contain 
the characters "0" to "9" or "*".) 



TP_PMR_1415_01 (Interoperability) TP_PMR_1415_02 (Interoperability) 



RQ_001_1317 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.3.2 



Type: Conditionally Optional 



Applies to: 
Requirement: 



Specification Text: 

Family: 

Test Purposes: 



Ml, M2, M3 

IF a dPMR radio is complying with the Standard User Interface 

THEN the radio may limit the number of digits that can be changed in any 
dialled address string, thereby limiting the addressable range from that radio. 

(The MS equipment may contain predefined parameters prescribing the minimum and 
maximum length of the user dial string. By limiting the length of the dialled string, the address 
range that the MS is able to dial is restricted.) 

TP_PMR_1418_01(Interoperability) TP_PMR_1418_02 (Interoperability), TP_PMR_1418_01 
(Conformance) TP_PMR_1418_02 (Conformance) TP_PMR_1418_03 (Conformance) 
TP_PMR_1418_04 (Conformance) 



RQ_001_1318 All Call 

TS 102 658 [1] VI. 1.1 Clause: §A.1.2.3.3 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: For a dPMR radio complying with the Standard User Interface the All Call 

dialled strings shall be dialled and encoded as follows: 
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The All Call dialled string "n******" (All Call within a prefix) 
User dialled string Air Interface ID Remark 
"0******" 18CC3E All Talkgroup IDO 

"1******" 2F23 62 All Talkgroup ID 1 

etc. etc. etc. 

..9******.. £^ QQ 32 All Talkgroup ID9 



The All Call dialled string: "******" is rnapped to the All Talkgroup ID15 and 
addresses all MSs irrespective of their prefix. 

User dialled string Air Interface ID Remark 

"*******" F8 33A6 All Talkgroup ID 15 

Specification Text: (The All Call dialled string "n******" (All Call within a prefix) is mapped as shown in 
table A.3. 

Table A. 3: Mapping of prefixed All Call to the AI 
User dialled string Air Interface ID Remark 
"0******" 18CC3E All Talkgroup IDO 

"1******" 2F23 62 All Talkgroup ID 1 

etc. etc. etc. 

"9******" El DC 82 All Talkgroup ID9 

The All Call dialled string: "******" is mapped to the All Talkgroup ID15 and addresses all 

MSs irrespective of their prefix. 

Table A.4, [1]: Mapping of all prefix call to the AI 

User dialled string Air Interface ID Remark 

••*******" p8 33 A6 All Talkgroup ID15) 



Family: 

Test Purposes: 



TP_PMR_1 3 1 8_0 1 (Conformance) TP_PMR_1 3 1 8_02(Conformance) 
TP_PMR_1318_03(Conformance) TP_PMR_1318_04 (Conformance) 



4.4.2 User defined functions 



RQ_001_1401 

TS 102 658 [1] VI 
Applies to: 
Requirement: 



Dialling Plan 

1.1 Clause: § A. 1.3.1 
M1,M2,M3 



Type: Conditionally Mandatory 



For a dPMR radio complying with the Standard User Interface dialled addresses 
are always read and dialled in the sense left to right. 

Specification Text: (All dialled strings, as defined in the clause A. 1.3 of the present document, are read from left to 
right and are dialled in the sequence in which they are read.)Throughout this clause all 
representations of dialled strings are underlined. 

MSs may only be required to dial sufficient numbers of characters unambiguously define the 
destination and service required. 

Family: No Duplicates 

Test Purposes: None 
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RQ_001_1402 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.1 Type: Optional 

Applies to: Ml, M2, M3 

Requirement: A dPMR radio complying with the Standard User Interface may support 

abbreviated dialling. 

Specification Text: A. 1.3.1 User numbering 

All dialled strings, as defined in the clause A. 1.3 [1], are read fi^om left to right and are dialled 
in the sequence in which they are read. Throughout this clause all representations of dialled 
strings are underlined. 

(MSs may only be required to dial sufficient numbers of characters unambiguously define the 
destination and service required.) 

Family: 

Test Purposes: TP_PMR_1417_01 (Interoperability) TP_PMR_1417_02 (Interoperability) TP_PMR_1417_03 

(Interoperabihty) , TP_PMR_1417_01 (Conformance) TP_PMR_1417_02 (Conformance) 

RQ_001_1403 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.1.1 Type: Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: IF the user has entered or selected the series of digits as required for the dialled 

address 

THEN a dPMR radio complying with the Standard User Interface shall also 
require the pressing of the "#" key or other dedicated send key to initiate the call. 

Specification Text: (To maximize channel utilization, the user should enter a string of digits and then press a 
button to initiate the call. 

The "#" key or a dedicated "send" key is used to initiate the call.)The "#" key has an additional 
purpose of modifying the call type or priority. 

Family: 

Test Purposes: TP_PMR_1403_01 (Conformance) TP_PMR_1403_02 (Conformance), TP_PMR_1403_01 

(Interoperability) 

RQ_001_1404 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.1.2 Type: Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: A dPMR radio complying with the Standard User Interface shall determine the 

type of call from user dialled string. The user should not have to also select call 
type. 

Specification Text: (Underlying signalling and system functionality is hidden from the user. MSs determine the 
call type and function from the length and content of the dialled string.) 

Family: No Duplicates 

Test Purposes: None 
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RQ_001_1405 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.13.1.3 Type: Conditionally Optional 

Applies to: Ml, M2, M3 

Requirement: In a dPMR radio complying with the Standard User Interface 

IF the dialled number is preceded by a hash "#" 

THEN the dialling function or call type may be modified. 

Specification Text: Dialled strings that commence with a hash "#" provide secondary uses for the keypad. 
Secondary dialling functions may be as follows: 

• status call; 

• broadcast call. 

(Secondary dialling is achieved by the use of call modifier strings in front of the dialled 
number. These call modifier sequences utilize the "#" and "*" keys.) 



Family: 

Test Purposes: 



lOP 1420 TP_PMR_1420_01(Interoperability) TP_PMR_1420_02 (Interoperability), 
TP_PMR_1420_01(Conformance) 



RQ_001_1406 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.2 



Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 



M1,M2,M3 

IF a dPMR radio is complying with the Standard User Interface 

AND abbreviated dialling is available 

THEN the abbreviated dialling shall operate as follows: 

An MS shall construct the called address by adding the most significant digits 
of its own ID to the entered digit string to form a complete destination address. 

Example 

An MS whose individual address is "1234567" (in the user domain), dials "43". 

MS own ID 1234567 

Dialled destination 43 

Full destination address 1234543 

In the User-Interface domain structure, if the string represents an MS address, and contains a 
"*" in any of the four least significant characters, then that MS address represents a group of 
MSs. 



Family: 

Test Purposes: 



(The length of destination MS address dialled digits is in the range from 1 to 7, and is 
interpreted as the right most digits of the recipient's number. The MSs individual address is 
used as a base address, and the right-most digits of that number are replaced by the user dialled 
digits, as shown in example 1 and 2. The resulting number is then converted to the AJ ID using 
the algorithm presented in the annex A, [1].) 

See example 1 in document. 



TP_PMR_1417_01(Interoperability) TP_PMR_1417_02 (Interoperability) TP_PMR_1417_03 
(Interoperability), TP_PMR_1417_01 (Conformance) TP_PMR_1417_02 (Conformance) 



RQ_001_1407 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.2 
Applies to: Ml, M2, M3 



Type: Conditionally Mandatory 
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Requirement: IF the radio is a dPMR radio 

AND the radio is complying with the Standard User Interface 
AND abbreviated dialling is available 
THEN the abbreviated dialling of a group address shall operate as follows: 

An MS shall construct the called address by adding the most significant digits 
of its own ID to the entered digit string to form a complete destination address. 

Example 

An MS whose individual address is "1234567" (in the user domain), dials "*" to 
place a group call. 

MS own ID 1234567 

Dialled destination * 

Full destination address 123456* 

(In the User-Interface domain structure, if the string represents an MS address, and contains a 
"*" in any of the four least significant characters, then that MS address represents a group of 
MSs.) 



Specification Text: 



Family: 

Test Purposes: 



The length of destination MS address dialled digits is in the range from 1 to 7, and is 
interpreted as the right most digits of the recipient's number. The MSs individual address is 
used as a base address, and the right-most digits of that number are replaced by the user dialled 
digits, as shown in example 1 and 2. The resulting number is then converted to the AI ID using 
the algorithm presented in the annex A, [1]. 

See example 2 in document 

TP_PMR_1415_01 (Interoperability) TP_PMR_1415_02 (Interoperability) 



RQ_001_1408 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.3.1 Type: Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: A dPMR radio complying with the Standard User Interface shall have at least 

one individual numeric address in the range 0000001 to 9999999 with the 
exception of the following: 

"1000000", "2000000", "3000000", "4000000", "5000000", "6000000", 
"7000000", "8000000", and "9000000". 

Specification Text: (An MS is allocated a numeric address in the range in the range "0000001" to "9999999", (see 

note). MSs may be programmed with more than one individual address. 
NOTE: The addresses "1000000", "2000000", "3000000", "4000000", "5000000", "6000000", "7000000", 
"8000000", and "9000000" are not valid.) 

Family: 

Test Purposes: None 
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RQ_001_1409 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.3.2 Type: Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: IF a dPMR radio complying with the Standard User Interface is programmed 

with more than one numeric address 

THEN any additional address may be a talkgroup address in the range 0000001 
to 9999999 with the exception of the following: 

"1000000", "2000000", "3000000", "4000000", "5000000", "6000000", 

"7000000", "8000000", and "9000000". 

Specification Text: (Talkgroups may be both all numeric numbers), or contain a "*" in any of the least significant 
four digits. 

Family: 

Test Purposes: TP_PMR_1415_01 (Interoperability) TP_PMR_1415_02 (Interoperability) 

RQ_001_1410 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.3.3 Type: Conditionally Mandatory 

Applies to: M1,M2, M3 

Requirement: A dPMR radio complying with the Standard User Interface shall always respond 

to call that has an all 'wild card' address, "*******" 

Specification Text: (All units respond to All MSs address "*******#") 

Family: 

Test Purposes: None 

RQ_001_1411 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.3.3 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Every dPMR radio complying with the Standard User Interface with the prefix 

(most significant digit) n shall respond to call that has an "n" prefix and 6 'wild 
cards', "n******". Where n can be to 9. 

i.e. any radios with an address "2nnnnnn" will respond to a call addressed to 

Specification Text: (All units with prefix "n" respond to the prefixed All MS address "n******#" 
with n=0 to 9.) 

Family: 

Test Purposes: None 
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RQ_001_1412 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.3.4 Type: Conditionally Mandatory 

Applies to: Ml, M2, M3 

Requirement: IF a dPMR radio is complying with the Standard User Interface 

THEN it shall not be possible for the radio to compose or send a non-dialable 

number. 

These numbers are: 

"0000000", "1000000", "200000", "300000", "4000000", "5000000", 
"6000000", "7000000", "8000000", "9000000". 

If a user enters any of these addresses the radio shall not send the call and give 
an appropriate error indication to the user. 

Specification Text: (MS addresses' "0000000", "1000000", "200000", "300000", "4000000", "5000000", 

"6000000", "7000000", "8000000", "9000000" are not dialable. If the user inputs a dialled 
string of digits that is not assigned to any of the dialling algorithms, then the MS should not try 
to establish the call and appropriate feedback given to the user.) 

Family: 

Test Purposes: TP_PMR_ 1 4 1 2_0 1 (Interoperability) 

RQ_001_1413 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3. 3.5.1 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: IF a dPMR radio is complying with the Standard User Interface 

AND all numeric talk groups are programmed 

AND a callee address has been entered 

THEN the MS shall be able to compare this address with its own talkgroup 

memory table and establish if the call is a talkgroup call. 

Specification Text: (Each MS has storage allocated for numeric talkgroup addresses. The table is populated during 
MS personalization by the user. The sender (MS) may use entries in this table to establish that 
the destination address is a talkgroup rather than an individual address.) 
The talkgroup table contains entries consisting of the full talkgroup address consisting of 
7 characters as shown in the example. 

EXAMPLE: The sender (MS) whose individual address is "1234561" has the destination "1234567" stored in 

its talkgroup table. The user enters a single digit "7" as the destination address. 

The full destination address is formed from the dialled digit(s) and the MS own individual 
address. 

MS source address 1234561 

Dialled destination 7 

Full (Talkgroup), see note 1234567 
NOTE: Destination address after processing. 

The talkgroup table is searched for a match. In this example there is a match so the destination 
address is a talkgroup addresses 

Family: No Duplicates 

Test Purposes: None 
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RQ_001_1414 

TS 102 658 [1] VI, 
Applies to: 
Requirement: 



Specification Text: 



EXAMPLE 1: 



Family: 

Test Purposes: 



Dialling Plan 

1.1 Clause: %A.\3.'i.5.2 rype; Conditionally Mandatory 

Ml, M2, M3 

IF a dPMR radio is complying with the Standard User Interface 

AND a callee address containing a wildcard is entered 
THEN the MS shall recognize that the call is a talkgroup call. 

(The dialled string is examined by the initiating MS. If the destination is identified as a 
talkgroup because the address contains a "wildcard" character in one of the four least 
significant digits then call set-up procedure is to a talkgroup as shown in the 
example. )Abbreviated dialling minimizes the number of dialled digits. An advantage of using 
"wildcard" to define talkgroups is that no pre-arrangement is necessary, i.e. there is no need for 
a talkgroup table or other MS configuration to recognize an address as a talkgroup. 

MS source address 1234561 

Dialled destination * 

Full destination address, (see note) 123456* 
NOTE: Destination address after processing. 

No Duplicates 

None 



RQ_001_1415 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3. 3.5.3 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: Upon receiving a call a dPMR radio complying with the Standard User Interface 

shall decode the 24 bit address field using the reverse B2 algorithm to recover 
the dialled digits. 

A: If the received digits contain a "*" in the digits K4 to K7 then each digit is 
compared in turn with the corresponding digit of the MS individual identity 
looking for a match. If an "*" is encountered then a match for that digit is 
assumed. 

B: If the received digits are all numeric then the digits Kl to K7 are compared 
with each of the entries in the talkgroup table looking for a match. 

If either A or B result in a match being found the radio will respond to the call as 
a talk group call. 

(The recipient MS applies the reverse B2 to recover the dialled digits Kl to K7. 

• If the received digits contain a "*" in the digits K4 to K7 then: 

- each digit is compared in turn with the corresponding digit of the MS individual 
identity looking for a match. If an "*" is encountered then a match for that digit is 
assumed. 

• If the received digits are all numeric then: 

- the digits Kl to K7 are compared with each of the entries in the talkgroup table 
looking for a match (after each entry in the table has been expanded to the full 7 address 
digits as described in clause A. 3. 3. 5.1, [1]). 

A match must exist for the MS to respond to the talkgroup call.) 



Specification Text: 



Family: 

Test Purposes: 



TP_PMR_1415_01 (Interoperability) TP_PMR_1415_02 (Interoperability) 
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RQ_001_1416 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.4.1.1 Type: Conditionally Optional 

Applies to: Ml, M2, M3 

Requirement: IF a dPMR radio is complying with the Standard User Interface 

The user may enter the full 7 digit address of the radio to be called. 

Specification Text: (A.1.3.4.1.1, [1] Seven digit dialling 

The user may enter the whole seven digit address to complete the dialled string prior to 

transmission. 

These seven digits may also contain wildcards.) 

Family: No Duplicates 

Test Purposes: TP_PMR_1416_01 (Conformance) 



RQ_001_1417 

TS 102 658 [1] VI, 
Applies to: 
Requirement: 



Specification Text: 



Family: 

Test Purposes: 



Dialling Plan 

1.1 Clause: %A.\3A.\.2 r>pe.- Conditionally Mandatory 

M1,M2,M3 

IF a dPMR radio is complying with the Standard User Interface 

AND abbreviated dialling is available 

THEN User entered digits shall be used as the least significant digits and the 

radio will use its own ID as the base number for any unentered digits. 

(Where abbreviated keypad dialling is used in the MS, the MS should insert the more 

significant characters from the MS individual address to complete the dialled string prior to 

transmission. 

Those digits entered may also include wildcards. 

If all digits are not dialled the more significant digits from the MS individual address are 

copied to the dialled string to build a seven digit address as follows: 

for the MS individual address "21 12345": 

• if the user dials 6#, the destination address shall be 21 12346; 

• if the user dials 56#, the destination address shall be 21 12356; 

• if the user dials 958#, the destination address shall be 21 12958; 

• if the user dials 1385#, the destination address shall be 21 1 1385; 

• if the user dials 13*5#, the destination address shall be 21 1 13*5 (talkgroup).) 



TP_PMR_1417_01 (Conformance) TP_PMR_1417_02 (Conformance), 

TP_PMR_1417_01(InteroperabiHty)TP_PMR_1417_02(Interoperability)TP_PMR_1417_03 

(Interoperability) 



RQ_001_1418 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.4.1.3 Type: Conditionally Mandatory 

Applies to: M1,M2, M3 

Requirement: IF a dPMR radio is complying with the Standard User Interface 

The radio may use a mask to limit the number of digits to be entered to be less 

than 7. 

Masked dialling may also be used in conjunction with abbreviated dialling. 
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Specification Text: 



Family: 

Test Purposes: 



(The number of digits of a dialling string that can be entered may be restricted by MS 

programming to restrict the number range accessible from the user interface. For example the 

user interface could mask the most significant digit of an address to prevent the MS from 

reaching other MSs outside its own prefix. 

Where masked dialling is used in the MS, the MS shall insert the characters from its own 

individual address that correspond to the each of the blocked positions to complete the dialled 

string prior to transmission. 

Masked dialling may also be used in conjunction with abbreviated dialling. 

Those digits entered may also include wildcards. 

Example: 

For the MS individual address of 3456789. 

The dialling string entry mask is [X] [X] [X] [X] [ ] [ ] [ ] 

The user may only enter digits in those positions not marked with an X. 

- If the user enters 888# then the resulting dialling string will be 3456888. 

- If the user enters 8# then the resulting dialling string will be 3456788 

If the user enters 88*# then the resulting dialling string will be 345688* (Talkgroup 
call)) 



TP_PMR_1418_01(Conformance) TP_PMR_1418_02 (Conformance) TP_PMR_1418_03 
(Conformance) TP_PMR_1418_04 (Conformance), , TP_PMR_1418_01 (Interoperability) 
TP_PMR_1418_02 (Interoperability) 



RQ_001_1419 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.4.3 



Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 



Ml, M2, M3 

IF a dPMR radio is complying with the Standard User Interface 

AND the user keys in a call modifier prefix of #1 * 

AND the dialled digits after this prefix correspond to a talk group address in the 

radio's memory 

THEN the radio shall set up a broadcast talk group call to that address. 

Functions such as the modification of call requests to change to type of service request, and the 
implementation of other facilities (status, broadcast, etc), are initiated using the syntax in the 
following clauses. The call modifier is defined by the dialled string by adding extra digits to 
the dialled destination in the form. 
# <call modifier code> * destination as defined in clauses A.1.3.4.3.1 to A.1.3.4.3.7, [1] 



Table A.5, [1]: Summary of call modifiers 

Dialled Digits Call Modifier 

#l*nn...# Broadcastcall, clause A.1.3.4.3.1, [1] 

#Oss*nn...# Status call, clause A.l. 3.4.3.4, [1] 

#6*nnn..# Force talkgroup service, clause A.1.3.4.3.7, [1] 

(A.3.4.2.1 Broadcastcall 

The MS shall set-up a broadcast call to the destination talkgroup nn by dialling "#l*nn#". 
The broadcast call shall be a normal group call but with the Communications Format set to 
'Call Air (Broadcast). 

EXAMPLE 1: "#1*112345*#" should make a broadcast talkgroup call to MS address 
"112345*". 
NOTE: The dialled string "#l*nnn". "#" should generate an error if the address is not a talkgroup address. 

EXAMPLE 2: If the MS calHng party address is "1234567". "#1 **#" should make a broadcast talkgroup call to 
"123456*" (i.e. to "1234560", "1234561", etc., "1234569")). 



Family: 

Test Purposes: 



TP_PMR_1419_01(Conformance) TP_PMR_1419_02 (Conformance) , TP_PMR_1419_03 
(Conformance) TP_PMR_1419_04 (Conformance) TP_PMR_1419_05 (Conformance) 
TP_PMR_1419_06 (Conformance) TP_PMR_1419_07 (Conformance), TP_PMR_1419_01 
(Interoperability) TP_PMR_1419_02 (Interoperability) 
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RQ_001_1420 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.4.3.5 



Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 



Family: 

Test Purposes: 



Ml, M2, M3 

IF a dPMR radio is complying with the Standard User Interface 

AND the user keys in a call modifier prefix of #Oss* 

AND the ss digits have a value of to 31 

THEN the radio shall send a status call to the address specified after the call 

modifier with the status bits set to the value entered. 

Entering a status value greater than 31 shall generate an error warning. 

Functions such as the modification of call requests to change to type of service request, and the 
implementation of other facilities (status, broadcast etc.), are initiated using the syntax in the 
following clauses. The call modifier is defined by the dialled string by adding extra digits to 
the dialled destination in the form. 

# <call modifier code> * destination as defined in clauses A.1.3.4.3.1 to A.1.3.4.3.7, [1]. 
Table A.1.3.4.2, [1]: Summary of call modifiers 
Dialled Digits Call Modifier 



#l*nn...# Broadcastcall, clause A.1.3.4.3.1, [1] 

#Oss*nn...# Status call, clause A.l. 3.4.3.4, [1] 

#6*nnn..# Force talkgroup service, clause A.1.3.4.3.7, 



[1] 



A.1.3.4.3.5,[l] Status call 

(The string "#Oss*nnn#" causes the MS to set up a status call to the destination address nnn. 

The status digits "ss" are numeric in the range to 31). 

The status call shall have the Header frame + End frame format of a status response call. 

Entry of a status value greater than 3 1 shall generate an error warning to the user. 

No Duplicates 

TP_PMR_1420_01 (Conformance), TP_PMR_1420_01 (Interoperability) TP_PMR_1420_02 
(Interoperability) 



RQ_001_1421 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.4.3.7 



Type: Conditionally Mandatory 



Applies to: 
Requirement: 



Specification Text: 



M1,M2, M3 

IF a dPMR radio is complying with the Standard User Interface 

AND the user enters a call modifier prefix of #6* 

AND the dialled digits after this prefix correspond to a talk group address in the 

radio's memory 

THEN the radio shall set up a talk group call to that address. 

Functions such as the modification of call requests to change to type of service request, and the 

implementation of other facilities (status, broadcast, etc.), are initiated using the syntax in the 

following clauses. The call modifier is defined by the dialled string by adding extra digits to 

the dialled destination in the form. 

# <call modifier code> * destination as defined in clauses A.1.3.4.3.1 to A.1.3.4.3.7 [1]. 

Table A.1.3.4.2 [1]: Summary of call modifiers 

Dialled Digits Call Modifier 

#l*nn...# Broadcast call, clause A.1.3.4.3.1 

#Oss*nn...# Status call, clause A. 1.3.4.3.4 

#6*nnn..# Force talkgroup service, clause A.1.3.4.3.7 

A.1.3.4.3.7 [1] Force talkgroup service 

(The string "#6*nnn..#" causes the MS to set up a talkgroup call to destination talkgroup nnn. 

where nnn. is a numeric string of length from 1 to 7 digits. 

EXAMPLE: To make a talkgroup call from MS 1 122345 to talkgroup MSs 1 122356 dial 

"#6*1122356#". In this case dialHng "#6*56#" would achieve the same result.) 
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Family: No Duplicates 

Test Purposes: TP_PMR_1 42 1_01 (Conformance) TP_PMR_1421_01 (Interoperability) TP_PMR_1421_02 

(Interoperability) 

RQ_001_1422 Dialling Plan 

TS 102 658 [1] VI. 1.1 Clause: §A.1.3.4.4 Type: Conditionally Mandatory 

Applies to: M 1 , M2, M3 

Requirement: IF a dPMR radio is complying with the Standard User Interface 

AND the user keys "##" following dialling an address and "#" terminator, 
AND the radio has not yet transmitted the call, 
THEN the radio shall not initiate the call. 

Specification Text: ("##" may be dialled after digits and a terminator have been entered on the keyboard. If the 
radio unit has not transmitted a call request, it shall abandon the call.) 

Family: 

Test Purposes: TP_PMR_1422_01 (Conformance) 
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